I like the idea of protecting as much as possible (the stack and the data area
should not be executable, from a purely conceptual point of view).
The patch sounds ugly to me, tho, because of the tricks required to work around
corner cases:
the signal problem can be solved independently from the binaries,
so it can be considered as a temporary kludge, but the trampoline problem is
more serious. Anybody wants to hack gcc to have it insert a "trampolines used
in this file" hint (and have ld.so dealk with it correctly), so that programs
not using trampolines are harder to break ?
(since trampolines are slow already, it's good to make them even less desirable
so that there is even more incentive to get rid of them. Their use in gcc is
very infrequent and the case of ObjectiveC is solved "easily" by (finally)
adding a GC and have real closures)
> And while I'm sympathetic to calls that we shouldn't break things like
> data segment executability for things like crashme, a possible
> compromise would be to have a system call that enabled or disabled
> things like data segment and stack segment executability. If you're
I seem to remember that other Unix variants have the data area exec-protected,
so any program that needs its data-area to be executable has already to go to
the trouble of deprotecting it on those platforms.
It would break some programs, but they would be easy to fix. (and in the mean
time, we can add hints to those programs that get broken, or alternately, add a
hint to the programs newly compiled indicating that they do follow the nice
practice of warning the OS before executing off the data-area)
Stefan