Fwd: Different stacks for return addresses and data?
|
From: kenney on 3 Mar 2010 05:44 In article <ebb91c9b-10af-42de-87a6-27243b001d6f(a)o3g2000yqb.googlegroups.com>, vorstadtkind(a)googlemail.com (Joris Dolderer) wrote: > I wondered whether it would be possible to use different stacks for > return addresses and data Stack based languages like Forth have used separate data and return stacks since they were developed. Some Forth implementations actually have more than two stacks with a separate stack for FP data and or a return stack that is different from the processor return stack. Ken Young
From: robertwessel2 on 3 Mar 2010 14:22 On Mar 3, 4:44 am, ken...(a)cix.compulink.co.uk wrote: > In article > <ebb91c9b-10af-42de-87a6-27243b001...(a)o3g2000yqb.googlegroups.com>, > > vorstadtk...(a)googlemail.com (Joris Dolderer) wrote: > > I wondered whether it would be possible to use different stacks for > > return addresses and data > > Stack based languages like Forth have used separate data and return > stacks since they were developed. Some Forth implementations actually > have more than two stacks with a separate stack for FP data and or a > return stack that is different from the processor return stack. Not really a good example. Forth programs heavily use the return stack to store data - while most operations on data happen on the data stack, temporary and local values are often stored on the return stack. What would not be common, however, is for a Forth program to allocate something like a string or buffer on the return (or data) stack, so the classic C buffer overflow/stack smash is not that likely in a Forth program. To the OP: There is no technical reason you could not set up x86 calling conventions to avoid return mingling return addresses with data on a single stack. For example, you could use the hardware stack (esp) for only return addresses and register saves, and manually manage a data stack referenced with ebp. You will, however pay a performance penalty since the generated code will have to work around some of the x86 hardware, but its certainly possible. In the split esp/ebp scenario I described, you'll have a bit more code to manage the data stack at entry and exit to routines, and building the parameter lists for calling a routine will also somewhat bigger, although neither has to be a huge difference. Something you don't want to do is bypass the existing x86 call/return architecture, since return address prediction in the hardware is heavily based on the use of the standard mechanisms, and messing that up that would typically involve a large performance hit. The other problem is that such a new calling convention will be incompatible with essentially everything else, including the system calling convention, and you'll need to implement some sort of glue code to hook this into existing systems.
From: Mike Hore on 3 Mar 2010 21:50 Stephen Fuld wrote: > On 3/1/2010 6:12 AM, Joris Dolderer wrote: >> Sorry for reposting, >> >> I didn't get this newsgroup at first. >> >> >> ---------- Forwarded message ---------- >> From: Joris Dolderer<vorstadtk...(a)googlemail.com> >> Date: Feb 28, 1:41 pm >> Subject: Different stacks for return addresses and data? >> To: comp.security.misc >> >> >> Hi, >> >> I wondered whether it would be possible to use different stacks for >> return addresses and data to eliminate the harm of buffer overflows >> except in unlikely circumstances (e.g. if you have function pointers >> saved in data structures) > > Other processors do exactly this. It has an advantage in that you can > have different protection for the data versus the return addresses. The KDF-9 of the '60s had a separate data and return stack - called "nesting store" and "subroutine jump nesting store" (SJNS). Quite sensible to keep data from getting mixed up with return addresses. The Burroughs machines only had (have) one stack, but it's a complex data structure with extra registers pointing into it etc. A whole different kettle of fish. Cheers, Mike. --------------------------------------------------------------- Mike Hore mike_horeREM(a)OVE.invalid.aapt.net.au ---------------------------------------------------------------
First
|
Prev
|
Pages: 1 2 Prev: Why does Intel favor thin rectangular CPUs? Next: GPGPU Programming/Architecture |