This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]