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

[Markus Gothe <nietzsche at lysator dot liu dot se>]

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.

//Markus

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
> > > 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.
>
> 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.
>
>  Ralf

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