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