trampolines: __disable_execute_stack ?

[Marc Espie]

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
to speak...