On Wed, 14 Mar 2012 17:25:28 -0400, deadalnix <[email protected]> wrote:
Le 14/03/2012 21:53, Steven Schveighoffer a écrit :
On Wed, 14 Mar 2012 16:45:49 -0400, Don Clugston <[email protected]> wrote:
On 14/03/12 21:31, Steven Schveighoffer wrote:
On Wed, 14 Mar 2012 16:08:29 -0400, Don Clugston <[email protected]>
wrote:
Now, your user space handler will cause another segfault when it does
the mov [ESP], 0. I think that gives you an infinite loop.
SEGFAULT inside a SEGV signal handler aborts the program (no way to
turn
this off IIRC).
-Steve
But you're not inside the signal handler when it happens. You returned.
Then how does the signal handler do anything? I mean, doesn't it need a
stack? Or does it just affect register variables? Most signal handlers
are normal functions, and isn't there some usage of the stack to save
registers?
It seems there should be a way to turn off the signal handler during the
time when you are suspicous of the stack being the culprit, then
re-engage the signal handler before throwing the error.
-Steve
The address of the instruction being executed is hijacked, so, instead
of resuming normal operation after the signal handler exit, it get into
the throwing handler.
This is a very nice trick !
I get that. What I was saying is, I thought even the signal handler uses
the stack (thereby it would abort if invalid). And even if it doesn't,
simply accessing the stack by loading it into a register should be
sufficient to "test" and see if the stack is valid to use (i.e. cause
another SEGV inside the signal handler forcing an abort so we don't have
an infinite loop).
I honestly don't know enough to really be discussing, but it seems like a
really neat idea, and I grasp how it works. I just don't know all the
particulars of signal calling conventions.
-Steve
