Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind

[Jeff Law <law at redhat dot com>]

On 08/02/2017 03:36 PM, Florian Weimer wrote:
> * Jeff Law:
> 
>> Something like setup a signal handler when we first start unwinding that
>> flags the error and tear it down when we're done unwinding?    Obviously
>> we can't do setup/tear down each time for each address.  Anyway, just
>> thinking outloud here...
> 
> Linux doesn't have per-thread signal handlers, so this doesn't work
> reliably.
Sigh.  There's probably a multitude of reasons why this wouldn't work :-)

> 
> If speed is not a concern, but reliability is, call fork (the system
> call, not glibc's wrapper which calls fork handlers) and do the work
> in a single-threaded copy of the process.  There, you can set up
> signal handlers as you see fit, and the VM layout won't change
> unexpectedly.
Speed is one of the concerns.  Essentially we're pondering an efficient
mechanism to know if a given code address is valid so that we know if we
should even try to unwind through a particular stack frame.

One could probably claim that in the EH path a call to msync shouldn't
be a concern.  I'm skeptical these days, but could be convinced that
it's tolerable.

> 
> To harden unwinding against corrupted tables or table locations, we'd
> have to change ld.so to make all critical data read-only after loading
> and remove the unwinder caches (with more help from ld.so instead).
> It would make sense to move the unwinder implementation into ld.so.
> With proper hardening, corrupted stacks would not be able to cause
> crashes anymore, either.
Yea.  I'm not sure if we're ready to suggest that kind of change yet,
but that may be the long term direction.

jeff