Stack unwinding requirements (was: Re: [PATCH 03/13] posix: Consolidate Linux nanosleep syscall)

[Florian Weimer <fweimer at redhat dot com>]

On 05/12/2017 08:30 PM, Adhemerval Zanella wrote:
> On 12/05/2017 15:21, Florian Weimer wrote:
> > On 05/12/2017 07:58 PM, Adhemerval Zanella wrote:
> > > +++ b/nptl/Makefile
> >
> > > +CFLAGS-nanosleep.c = -fexceptions -fasynchronous-unwind-tables
> >
> >
> > > +++ b/posix/Makefile
> >
> > > +CFLAGS-nanosleep.c = -fexceptions
> >
> > Why the discrepancy?  I suppose both implementations could be called in a multi-threaded program.
>
> I do not recall a reason why these are different, I will set both to
> -fexceptions -fasynchronous-unwind-tables.  AFAIK -fexception is the
> required flag for cancelable syscall to work correctly, while
> -fasynchronous-unwind-tables is make it work also through signals
> (not really sure though).  So I would say to be safe we should set
> both.

glibc itself no longer uses the libgcc unwinder and the 
__gcc_personality_v0 personality routine.  As far as I know, the C front 
end never supported exceptions in this way, and we have since removed 
all assembly routines which used this functionality.

The replacement is a chain list of cleanup routines, rooted in a 
thread-local variable.  Cleanup code is specified by function pointers 
on the stack.  From a security perspective, this is far worse than 
unwinding based on tables stored in read-only memory.  We can likely 
obfuscate the function pointers (like we do for setjmp buffers), but 
that's it.

Technically, __gcc_personality_v0 is part of the ABI, so there could 
still be user code out there that uses it.  And of course, Ada and C++ 
code which is called from glibc code (or which runs from a signal 
handler that interrupts glibc code) could have stack frames with crucial 
unwinding information when thread cancellation happens.

In order to reach those stack frames, the cancellation code needs to 
unwind through glibc code.  This could be any code in glibc which calls 
a function which is a cancellation point.

Based on that, I think we should compile all of glibc with unwinding 
support, and considering that asynchronous cancellation can happen 
through synchronous cancellation within signal handlers, we need both 
-fexceptions *and* -fasynchronous-unwind-tables.

Comments?

Thanks,
Florian