This is the mail archive of the
mailing list for the GCC project.
Re: trampolines: __disable_execute_stack ?
On Tue, Jan 18, 2005 at 11:43:03AM -0800, Richard Henderson wrote:
> On Tue, Jan 18, 2005 at 10:31:20AM -0800, Zack Weinberg wrote:
> > 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.)
> Because non-local goto doesn't respect that mechanism.
> The only thing I've thought of before that would have a chance of
> working is an external trampoline manager that garbage collects
> based on the stack base/depth. With the advantage that it would
> be explicitly allocating anon mmap pages with the X bit set.
> On the other hand, my feeling is that trampolines are either
> non-existant in the application, or common. For the former, we
> never enable the X bit; for the later it would be a waste of time
> to turn it off afterward. Thus I am more or less happy with the
> PT_GNU_STACK solution we currently have.
This more or less corresponds to some of my feelings.
The solution I'm currently developping for OpenBSD includes
-ftrampolines and -Wtrampolines flags.
Since we're paranoid about security, trampoline code won't compile
without the first flag (well, as for GCC itself, you could default
to -ftrampolines and have -fno-trampolines) and -Wtrampolines warns
instead, so that people concerned about security issues can look better
at the code.
Yes, I know, yet another set of flags...
Well, I don't see how to fold them with other stuff, since what I'm
looking at is very specific: those are applications that violate the
`non-execute stack' rule we have in place. `Normal' code can be audited
for mprotect calls, but trampoline stuff happens `behind the scene' so