Non-executable stack

[Julian Elischer]

martinko wrote:

> 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.
>>>
>>> DES
>>>  
>>>
>> _______________________________________________
>> freebsd-security at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-security
>> 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 
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.

>
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to 
> "freebsd-security-unsubscribe at freebsd.org"