This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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 to make all critical data read-only after loading
> and remove the unwinder caches (with more help from instead).
> It would make sense to move the unwinder implementation into
> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]