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

[Jeff Law]

On 08/03/2017 11:03 AM, Florian Weimer wrote:
> * Jeff Law:
> 
>>> 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.
> 
> I thought this was debugging-only, optional unwinder behavior.
My understanding was this was in the EH path as well.  If it's outside
the EH path, then I don't care about the cost of msync and the like :-)

> 
>> 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.
> 
> Efficient code address validation is possible using data structures
> maintained by ld.so.  If those data structures are mostly read-only,
> they cannot be corrupted, so pointers and offsets in them don't have
> to be validated before derefencing them.
Understood.

> 
> But the main problem is the frame pointer chain, and the current lack
> of registration for stacks.  The program can just malloc some area,
> switch the SP, and start running from there.  Some libraries do
> exactly that.  And without knowledge of the bottom address of the
> stack, it is impossible to verify that the frame pointer chain goes
> somewhere off the stack.
Yea.

> 
>> 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.
> 
> Quite a few applications are sensitive to EH performance.  The current
> freshness check for the cache is very inefficient, which is a
> significant problem for some users.  If we can push out the flag check
> the top level (essentially compiling the unwinder twice, with and
> without checking), I don't think this would cause significant
> additional performance issues.
Yea.  I went back and reviewed the internal BZ.  It's actually just the
print-a-backtrace thing rather than EH unwinding.  SO yea, if the
print-a-backtrace path and EH path both use bits, we could just compile
them twice, once with checking once without respectively.


Jeff