martinko wrote:
Julian Elischer wrote:
Dag-Erling Smørgrav wrote:
db <[EMAIL PROTECTED]> writes:
Memory on ia32 can be writable and readable. When it is readable it
is also executable. On other arch's like AMD64 and IA64, I believe
memory can be readable, writable and executable.
Not quite. IA32 can make individual segments readable, writable and /
or executable, but lacks the ability to do so on a per-page basis.
Since we have trampoline code at the top of the stack, the entire
stack segment must be executable. Moving the trampoline off the stack
would solve the problem on all platforms.
There has been recent talk of a shared kernel/user memory page..
that could be used for trampoline code.
W^X across the board is not an option - it would break HotSpot and
other JIT-based software.
DES
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
and what exactly is that trampoline btw/pls ?
the way that signals are deliverred in non threaded code, is that they
are always
delivered when the processor is returning to userland after having been
in the
kernel for some reason (a hardware interrupt, or a sheduler change or a
syscall
or a pagefault, it doesn't matter why).
The kernel places code on the user stack, that calls the
signal handler and then returns, returning to whatever is next on the
stack,
which is the return address that it would have gone to when returning from
the kernel had the signal not happenned. The code has to know how to get
ready
to call a signal handler, call it and cleanup anything that needs to be
cleaned up
after a signal handler. It's placed on the stack as it's guaranteed to
exist and it all
cleans up after itself., requiring no further work from the kernel. It
does however
require that the stack is executable.
it allows the kernel to always supply a working signal handling stub.
With a shared page (readonly to the user), the kernel could permanently
place a
good stub handler there.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to
"[EMAIL PROTECTED]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
