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

[Yury Gribov <tetra2005 dot patches at gmail dot com>]

On 02.08.2017 20:02, Jeff Law wrote:
> On 08/02/2017 12:47 PM, Jakub Jelinek wrote:
> > On Wed, Aug 02, 2017 at 12:38:13PM -0600, Jeff Law wrote:
> > > On 07/17/2017 01:23 AM, Yuri Gribov wrote:
> > > > I've rebased the previous patch to trunk per Andrew's suggestion.
> > > > Original patch description/motivation/questions are in
> > > > https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html
> > > Is his stuff used for exception handling?  If so, doesn't that make the
> > > performance a significant concern (ie that msync call?)
> >
> > For the performance issue, I wonder if it wouldn't be better to just
> > compile the unwinder twice, basically include everything needed for the
> > verification backtrace in a single *.c file with special defines, and
> > not export anything from that *.o file except the single entrypoint.
> > That would also handle the ABI problems.
> Yea.
>
> Given that the vast majority of the time the addresses are valid, I
> wonder if we could take advantage of that property to keep the overhead
> lower in the most common cases.
>
> > For the concurrent calls of other threads unmapping stacks of running
> > threads (that is where most of the verification goes against), I'm afraid
> > that is simply non-solveable, even if you don't cache anything, it will
> > still be racy.
> Absolutely -- I think solving this stuff 100% reliably without races
> isn't possible.  I think the question is can we make this significantly
> better.

All,

First of all, thanks for the feedback.  This is indeed not a 100% robust 
solution, just something to allow tools like Asan to produce more sane 
backtraces on crash (currently when stack is corrupted they would crash 
in the unwinder without printing at least partial backtrace).

I probly put this aside for now given that people in community don't 
find it too useful.  Should I close PR 67336 then?

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

Hm, I think I could sigsetjmp for SIGSEGV/SIGBUS before calling unwinder 
and then
* siglongjmp back on error (if signal is caught in unwinding thread)
* call users handler (for all other threads)

It's not clear how this is going to work in presense of nested signals 
though.  I could clear sigprocmask during execution of safe unwinding to 
prevent them but this sounds too gross...

-Y