This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
RE: [PATCH, RFC] MIPS: Implement the getcontext API
> -----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.