[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Two issues with stack overflow protection
From: |
Eli Zaretskii |
Subject: |
Re: Two issues with stack overflow protection |
Date: |
Wed, 29 Jul 2015 19:24:57 +0300 |
> Date: Wed, 29 Jul 2015 06:18:17 -0700
> From: Paul Eggert <address@hidden>
>
> 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?