This is the mail archive of the
mailing list for the GCC project.
Re: trampolines: __disable_execute_stack ?
- From: Zack Weinberg <zack at codesourcery dot com>
- To: espie at nerim dot net
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 18 Jan 2005 10:31:20 -0800
- Subject: Re: trampolines: __disable_execute_stack ?
- References: <20050118112146.GA3526@tetto.home>
Marc Espie <firstname.lastname@example.org> writes:
> On some OSes, having the stack non executable is a security decision.
> The current model of gcc does turn the stack executable to run trampolines,
> and then, that's all....
> Would it be possible to have a finer model, where you could possibly (if
> it's defined) call later a __disable_execute_stack, once you've called
> your trampoline.
I don't see why not. The appropriate point to call it would be when
the function that created the trampoline returns, and you could use
the WITH_CLEANUP_EXPR/ CLEANUP_POINT_EXPR mechanism to guarantee that
this would happen. (Think of the trampoline object as a C++ object
with a destructor.)
The semantics might be tricky, though. In the case where there are
two trampolines on the same page of the stack, you mustn't make the
outer one unexecutable when the inner one goes out of scope. Off the
top of my head I can't think of any way to do this other than to add
new mprotect() flags that implement a per-page stack of execute bits.
As an alternative, you might consider having the memory-fault handler
notice when a 'jump to unexecutable page' fault has triggered because
of a trampoline, and simulate the trampoline's execution. The
trampoline code sequence is very short and stereotyped, so it's not
hard - for instance, on x86 it will always be the sequence
b9 nn nn nn nn # movl $0xnnnnnnnn, %ecx
e9 mm mm mm mm # jmp $0xmmmmmmmm
I wouldn't be surprised if that was just as fast or faster than
calling mprotect() twice per trampoline.