Re: [PATCH, RFC] MIPS: Implement the getcontext API

[David Daney <ddaney@caviumnetworks.com>]

David VomLehn (dvomlehn) wrote:
>> -----Original Message-----
>> From: linux-mips-bounce@linux-mips.org 
>> [mailto:linux-mips-bounce@linux-mips.org] On Behalf Of Ralf Baechle
>> Sent: Wednesday, March 04, 2009 7:44 AM
>> To: Brian Foster
>> Cc: David Daney; Maciej W. Rozycki; 
>> linux-mips@linux-mips.org; libc-ports@sourceware.org; Maciej 
>> W. Rozycki
>> Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
>>
>> On Wed, Mar 04, 2009 at 09:19:28AM +0100, Brian Foster wrote:
>>
>>> On Tuesday 03 March 2009 17:56:25 David Daney wrote:
>>>> [ ... ]
>>>> When (and if) we move the sigreturn trampoline to a vdso 
>> we should be
>>>> able to maintain the ABI.
>>>  it's more a matter of "when" rather than "if".
>>>  there is still an intention here to use XI (we
>>>  have SmartMIPS), which requires not using the
>>>  signal (or FP) trampoline on the stack.
>>>
>>>  moving the signal trampoline to a vdso (which
>>>  is(? was?) called, maybe misleadingly, 'vsyscall',
>>>  on other architectures) is the obvious solution to
>>>  that part of the puzzle.  and yes, it is possible
>>>  to maintain the ABI; the signal trampoline is still
>>>  also put on the stack, and modulo XI, would work if
>>>  used - the trampoline-on-stack is simply not used
>>>  if there is a vdso with the signal trampoline.
>> We generally want to get rid of stack trampolines.  
>> Trampolines require
>> cacheflushing which especially on SMP systems can be a rather 
>> expensive
>> operation.
> 
> If I understand this correctly, using a vdso would allow a stack without
> execute permission on those processors that differentiate between read
> and execute permission. This defeats attaches that use buffer overrun to
> write code to be executed onto the stack, a nice thing for more secure
> systems.
> 

With one caveat, software other than the Linux kernel depends on an 
executable stack (GCC's nested functions for example).  All users of the 
executable stack would have to modified before you could universally 
make the switch.

That said, we do have RI/XI working well in our kernel (for non-stack 
memory), so it is something we are interested in pursuing.

David Daney