Re: Two issues with stack overflow protection

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 29 Jul 2015 06:18:17 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> Daniel Colascione wrote:
> >>> What's wrong with just mprotecting a guard page at the end of the stack,
> >>> >>and on overflow, giving that region normal protection, unwinding as
> >>> >>normal, then, at top level, restoring the guard page?
> >> >
> >> >Unwinding can grow the stack.
> > Sure. That's why you open up more stack to do the unwinding. Having done
> > that, if you still overflow, just abort.
> 
> Yes, that was my point.  Emacs already does the business about the guard page, 
> and opening up more stack, and so forth.  The tricky part is the "if you still 
> overflow, just abort", something that's easy enough to describe at the high 
> level but perhaps not so easy to actually write the code.  Part of the issue is 
> that the guard page business is done under the covers by the OS, not by Emacs 
> directly -- in general Emacs doesn't know where the guard page(s) are.

Maybe I'm missing something, but none of the data structures involved
in "normal" throw to top-level are on the stack, right?  So why cannot
we call the equivalent of (top-level) _after_ we sig_longjmp out of
the signal handler?