Re: Saving errno around signal handlers

[Rich Felker <dalias at aerifal dot cx>]

On Sat, Mar 01, 2014 at 03:05:05AM -0500, Carlos O'Donell wrote:
> On 02/28/2014 07:30 PM, Rich Felker wrote:
> > Of course I don't see why you even want to do this. The direction
> > POSIX is taking is to require applications to save and restore errno
> > if they might clobber it in the signal handler. There is no reason to
> > introduce lots of complexity, overhead, and runtime latency to signal
> > handling in glibc to accommodate programs which do not follow this
> > requirement.
> 
> Would it be OK if the program was compiled specifically with some
> security hardening options? The point being to prevent any possibility
> of a signal handler from modifying the thread errno.

The only objection I see to this is the complexity of implementing it
and the risk that you mess up a corner case nobody has thought of in
the synchronization considerations and thereby weaken the library when
you intended to harden it. The option Florian seems to be proposing
(using per-handler trampolines instead of synchronization) avoids the
obvious need for synchronization but I don't think you can fully avoid
it unless you're willing to allocate a new trampoline for each handler
installed and never free them (it's virtually impossible to determine
that they're no longer in use) and there are also security
implications to constructing trampolines at runtime (IIRC some
hardened kernels may not even allow pages to be made executable unless
they're backed by a file).

Rich