This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: trampolines vs nonexecutable stack
Richard Henderson <rth@redhat.com> writes:
> > Is there prior art for getting trampolines to work under this restriction,
> > malloc'd storage or something? Thanks.
>
> Folks have proposed things like this before: an on-the-side stack of
> trampolines in executable memory somewhere else. The kink is that
> you'd want to hook into longjmp and other things that manipulate the
> main program stack in the same way. Which in many cases would require
> ABI changes in jmp_buf et al because there isn't room for another
> pointer. You may be in a unique position for that not to be a problem
> right now.
I don't see why you need a pointer. Anything which manipulates the
program stack must presumably move it toward the top of the stack. At
that time you can examine the stack of trampolines and remove the ones
you no longer need. If you forget, it doesn't matter, though you may
run out of entries in the stack.
If you are OK with changing heap memory to be executable, then using
malloc would be straightforward although I don't know of any existing
implementations. That would give you just as much vulnerability as
making the stack executable, though. I suppose you could invent a new
call, executable_malloc, which returns space in pages specifically
marked executable, such that nothing else returned space in those
pages.
If your goal is just to prevent buffer overflow exploits, then I agree
that you should just do the call to make the stack executable, or put
a bit in the program header (ideally with a bit in the .o files,
rather than the rather awkward section mechanism used on GNU/Linux).
Very very few real C/C++ programs need trampolines.
Ian