julian at elischer.org
Thu Nov 3 16:23:51 PST 2005
> Julian Elischer wrote:
>> Dag-Erling Smørgrav wrote:
>>> db <db at traceroute.dk> 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.
>> freebsd-security at freebsd.org mailing list
>> To unsubscribe, send any mail to
>> "freebsd-security-unsubscribe at freebsd.org"
> and what exactly is that trampoline btw/pls ?
the way that signals are deliverred in non threaded code, is that they
delivered when the processor is returning to userland after having been
kernel for some reason (a hardware interrupt, or a sheduler change or a
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
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
to call a signal handler, call it and cleanup anything that needs to be
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
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
good stub handler there.
> freebsd-security at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-security-unsubscribe at freebsd.org"
More information about the freebsd-security