[Top] [All Lists]

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

To: Ralf Baechle <>
Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
From: Markus Gothe <>
Date: Thu, 16 Apr 2009 05:46:56 +0200
Cc: "David VomLehn (dvomlehn)" <>, Brian Foster <>, David Daney <>, "Maciej W. Rozycki" <>,,, "Maciej W. Rozycki" <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <> <>
That article is a classic one, just the name itself...

However the article itself is based on M68K and Intel x86 IIRC.

Indeed, IRIX < 6.2 was all o32, correct me if I'm wrong.

To get back on track, what about a kernel that can be compiled by MIPSPro C and not relaying on glibc and GNUisms (al right, 'asmlinkage' cracked that idea once and for all a few years ago), but my point is to change the libc as little as possible.

I hope I brought a grasp of light on the issue (and yes $ra is fun to play with), and as Ralph pointed out: the special stack frame makes the return address traceability disappear after one step as __GNUC__ knows it.


On 2 Apr 2009, at 15:38, Ralf Baechle wrote:

On Wed, Mar 04, 2009 at 05:25:35PM -0500, David VomLehn (dvomlehn) wrote:

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

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

The good news is that many of these stack buffer overruns don't work on MIPS anyway due to the somewhat unusual stack frame. Don't rely on that
too much for security though - like 10 years ago Phrack published an
article under the title "Smashing the stack for fun and profit" explaining
how to write exploits for IRIX 5 which als was using o32.


Attachment: PGP.sig
Description: This is a digitally signed message part

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