linux-mips
[Top] [All Lists]

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

To: "David VomLehn (dvomlehn)" <dvomlehn@cisco.com>
Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
From: David Daney <ddaney@caviumnetworks.com>
Date: Wed, 04 Mar 2009 14:34:16 -0800
Cc: Ralf Baechle <ralf@linux-mips.org>, Brian Foster <brian.foster@innova-card.com>, "Maciej W. Rozycki" <macro@codesourcery.com>, linux-mips@linux-mips.org, libc-ports@sourceware.org, "Maciej W. Rozycki" <macro@linux-mips.org>
In-reply-to: <FF038EB85946AA46B18DFEE6E6F8A289BE0B68@xmb-rtp-218.amer.cisco.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <alpine.DEB.1.10.0902282326580.4064@tp.orcam.me.uk> <49AD6139.60209@caviumnetworks.com> <200903040919.29294.brian.foster@innova-card.com> <20090304154418.GA13464@linux-mips.org> <FF038EB85946AA46B18DFEE6E6F8A289BE0B68@xmb-rtp-218.amer.cisco.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.19 (X11/20090105)
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

<Prev in Thread] Current Thread [Next in Thread>