[PATCH, RFC] MIPS: Implement the getcontext API

[David VomLehn (dvomlehn)]

> -----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.