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

[Florian Weimer]

* 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.

> 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.

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.

> 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.