[03/13] posix: Consolidate Linux nanosleep syscall

  This patch consolidates the nanosleep Linux syscall generation on
sysdeps/unix/sysv/linux/nanosleep.c.  It basically removes it from
architectures auto-generation list.

Checked on i686-linux-gnu, x86_64-linux-gnu, x86_64-linux-gnux32,
arch64-linux-gnu, arm-linux-gnueabihf, powerpc64le-linux-gnu,
sparc64-linux-gnu, and sparcv9-linux-gnu.

	* nptl/Makefile (CFLAGS-nanosleep.c): New rule.
	* posix/Makefile (CFLAGS-nanosleep.c): Likewise.
	* sysdeps/unix/sysv/linux/nanosleep.c: New file.
	* sysdeps/unix/sysv/linux/syscalls.list: Remove nanosleep from
	auto-generated list.
---
 ChangeLog                             |  6 ++++++
 nptl/Makefile                         |  1 +
 posix/Makefile                        |  1 +
 sysdeps/unix/sysv/linux/nanosleep.c   | 30 ++++++++++++++++++++++++++++++
 sysdeps/unix/sysv/linux/syscalls.list |  1 -
 5 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 sysdeps/unix/sysv/linux/nanosleep.c
  

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.

Thanks,
Florian
  

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.
  

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
  

On Mon, 15 May 2017, Florian Weimer wrote:

> 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.

See <https://sourceware.org/ml/libc-alpha/2015-10/msg00569.html> and 
followups for discussion of the circumstances when those options may be 
needed.
  

On 05/15/2017 01:36 PM, Joseph Myers wrote:

> See <https://sourceware.org/ml/libc-alpha/2015-10/msg00569.html> and
> followups for discussion of the circumstances when those options may be
> needed.

Interesting.  So the C frontend can actually generate code which invokes 
the personality routine (via the cleanup attribute).

I wonder if we can use this to make cancellation safer, at least within 
glibc.

Florian