David VomLehn (dvomlehn) wrote:
-----Original Message-----
From: linux-mips-bounce@xxxxxxxxxxxxxx
[mailto:linux-mips-bounce@xxxxxxxxxxxxxx] On Behalf Of Ralf Baechle
Sent: Wednesday, March 04, 2009 7:44 AM
To: Brian Foster
Cc: David Daney; Maciej W. Rozycki;
linux-mips@xxxxxxxxxxxxxx; libc-ports@xxxxxxxxxxxxxx; 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
