When you say "those executing code on the stack will have stack
execution permission automatically enabled" you do realize that any
program which has a signal delivered to it will "execute code on the
stack" via the kernel itself? Since just about every program I know
of which is of any utility takes a signal now and then during normal
operation, doesn't this turn off your protection in enough cases to
make it of little use?
The basic idea is that buffer exploit calls rely on executing code after
a "return" instruction. The trampoline codes generated by compilers
apparently do so using a jump instruction, so you can tell the
difference.
So if the EIP changes to a stack instruction, you take a GPF, and then
you figure out how you got there; if it was via a return instruction,
you assume it was due to a buffer exploit bug.
Solar (sorry I don't know your real name), have you checked to make sure
none of the trampoline codes call subroutines from stack code? If so,
then a user-space return instruction back into trampoline code might
erroneously cause your GPF handler to conclude that a buffer exploit was
in progress.
Another problem --- if a signal handler doesn't actually return, but
instead uses longjmp(), the CS register won't be reset, and you will no
longer be protected against executable code on the stack (since now the
CS segment register will be HUGE_CS which does allow stack execution).
Short of futzing with the longjmp()/setjmp() implementaiton, though,
there probably isn't much you can do about this.
- Ted