This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
MIPS RI/XI & trampolines [was:- [PATCH, RFC] MIPS: Implement the getcontext API ]
- From: Brian Foster <brian dot foster at innova-card dot com>
- To: David Daney <ddaney at caviumnetworks dot com>
- Cc: "David VomLehn (dvomlehn)" <dvomlehn at cisco dot com>, Ralf Baechle <ralf at linux-mips dot org>, "Maciej W. Rozycki" <macro at codesourcery dot com>, linux-mips at linux-mips dot org, libc-ports at sourceware dot org, "Maciej W. Rozycki" <macro at linux-mips dot org>
- Date: Thu, 5 Mar 2009 08:58:31 +0100
- Subject: MIPS RI/XI & trampolines [was:- [PATCH, RFC] MIPS: Implement the getcontext API ]
- References: <alpine.DEB.1.10.0902282326580.4064@tp.orcam.me.uk> <FF038EB85946AA46B18DFEE6E6F8A289BE0B68@xmb-rtp-218.amer.cisco.com> <49AF01E8.80705@caviumnetworks.com>
- Reply-to: Brian Foster <brian dot foster at innova-card dot com>
On Wednesday 04 March 2009 23:34:16 David Daney wrote:
> David VomLehn (dvomlehn) wrote:
> >> -----Original Message-----
> >> Sent: Wednesday, March 04, 2009 7:44 AM
> >> From: [...] On Behalf Of Ralf Baechle
> >>
> >> 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.
> >>>[ ... ]
> >> 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.
correct, albeit there are at least two caveats;
one is, as David points out, (pointer-to) GCC nested
functions; the other is the MIPS FP trampoline.
> 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,
I am Very Interested in this. we also want RI/XI,
at least for for userland (and, very importantly,
including the stack), but haven't yet time to deal
with the issue. (our platform is the 4KSd, which
has SmartMIPS (and thus has RI/XI)).
is what you have at linux-mips.org someplace?
cheers!
-blf-
--
âHow many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.â | http://www.stopesso.com