Sean Eric Fagan and I discussed this several years ago, and we
discussed it again the other day, before this attack hit. It
looks like it's an idea whose time has come.
We've identified a number of issues that might make doing this
problematic, and on which there needs to be feedback:
o Java; specifically, JITs may rely on an executable
stack. Neither of us knows if this is true, for
o FORTH? Same question.
o Julian's new threads patches
o Multiple architecture support
Right now, SEF points out (and I concur) that the only portion
of the system that seems to care about having an executable stack
is the signal trampoline. I would imagine that the trampoline
for the user space threads scheduler for KSE based threading will
(does) have the same problem.
For signals, this is easy: copy SVR4, and modify the signal
functions to pass in a return address, then disable the execute
bits on stack pages and see whose head blows up.
Frankly, I'm very surprised to discover that OpenBSD has not
already done this.
Opinions? Patches from people who know and love the signals
facility on Alpha, SPARC64, PPC, etc.?
The sparc64 signal trampoline is already in libc, I'm running a kernel
which maps the stack non-executable locally.
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message