Re: Solaris 7 x86 lpset exploit.

[Casper.Dik () HOLLAND SUN COM (Casper Dik)]

> If you longjmp out, how do you free up the jumped-through frames on the
> executable stack?  If you do it by using a contiguous executable stack
> with an offset-style pointer into it, conceptually the way longjmp
> deals with freeing ordinary stack frames, how do you deal with
> overflow, without wasting large amounts of data segment space on
> programs that don't need deep executable stacks?  If you do it with a
> linked list of frame structures, how do you push frames on it without
> risking either a corrupted stack or a lost frame in the presence of
> longjmp out of a signal handler?  If you do it with something else,
> well, what?

Not to mention the fact that building a second stack in the data
segment is *much* harder to do in a threaded environment.  You need
one stack per thread.

> Someone else said - I don't have the quote handy - that modern gcc
> calls mprotect() after setting up a trampoline.  The notion of doing a
> *syscall* per entry to a routine that uses trampolines, even when the
> system may not need it (may have the stack executable already), that
> makes me shudder.  I trust this can be turned off at compile time?  I'd
> really hate to have to dummy out mprotect() just to get minimally sane
> call performance.  (Oh, and what gcc version is that?)

It's not quite that bad.  First of all, the tampolines are
the exception.  They're only needed when you pass a nested function
as a parameter.  Perhaps only in C, as in other languages you can define
the ABI such that a function pointer is larger.  And in C, you shouldn't
be using nested functions in the first place.

Secondly, the code will use a syscall to determine whether the stack
is executable or not.  The result of this call is cached.  Mprotect
is only called when it is required.

Note that the trampoline code is already heavily dependent on the kernel;
in some cases the routines that flush the icache lines trap into the
kernel anyway.

Casper