This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH, RFC] MIPS: Implement the getcontext API
- From: Ralf Baechle <ralf at linux-mips dot org>
- To: Markus Gothe <nietzsche at lysator dot liu dot se>
- Cc: "David VomLehn (dvomlehn)" <dvomlehn at cisco dot com>, Brian Foster <brian dot foster at innova-card dot com>, David Daney <ddaney at caviumnetworks dot com>, "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: Fri, 17 Apr 2009 07:53:17 +0200
- Subject: Re: [PATCH, RFC] MIPS: Implement the getcontext API
- 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> <20090402133855.GC15021@linux-mips.org> <5A24253D-8F6F-46CE-A121-AD5CADC6D7C8@lysator.liu.se>
On Thu, Apr 16, 2009 at 05:46:56AM +0200, Markus Gothe wrote:
> That article is a classic one, just the name itself...
>
> However the article itself is based on M68K and Intel x86 IIRC.
There is a variant or extension of it which specifically looks at MIPS
o32 issues.
> 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.
Do you have a MIPSpro compiler that is hosted on a non-IRIX? Asmlinkage
is just an empty define.
> 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.
The first problem with the usual stack smashing techniques is that the
return address of a leaf function is not getting stored on the stack at
all, so can't be smashed by a stack overflow. So the caller's return
address is becoming the new attack target.
Ralf
PS: Who's that Ralph?