Prev: Why does Intel favor thin rectangular CPUs?
Next: GPGPU Programming/Architecture
From: Joris Dolderer on 1 Mar 2010 09:12
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)

I don't think you even had the need to make x86-incompatible
processors; you just would have to specify alternatives to push and
pop writing to a dedicated data stack...

Does anything speak against this?

Greetings,

Joris
From: Stephen Fuld on 1 Mar 2010 11:28
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.


--
- Stephen Fuld
(e-mail address disguised to prevent spam)
From: nmm1 on 1 Mar 2010 14:46
In article <ebb91c9b-10af-42de-87a6-27243b001d6f(a)o3g2000yqb.googlegroups.com>,
Joris Dolderer <vorstadtkind(a)googlemail.com> wrote:
>
>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)

It's possible. It's been done. It's often quite a lot faster
(better locality). Actually, you put addresses and scalars on
the primary stack, together with the stack frames, and put the
arrays and stack-scope dynamic objects on the secondary. It was
widely done for Algol 68, and sometimes PL/I.

>I don't think you even had the need to make x86-incompatible
>processors; you just would have to specify alternatives to push and
>pop writing to a dedicated data stack...

You don't.

>Does anything speak against this?

People have forgotten how to do it. I believe some Ada compilers
do it, but that's about all.


Regards,
Nick Maclaren.
From: Stefan Monnier on 1 Mar 2010 16:36
> 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)

Do people still waste time trying to make buffer-overflows slightly less
damaging rather than just ruling them out?


Stefan
From: "Andy "Krazy" Glew" on 1 Mar 2010 18:01
Stefan Monnier wrote:
>> 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)

Different stacks. Good idea. Done many times. E.g. Itanium.

Only real issue that I am aware of is compatibility. You need to define a new ABI (Application Binary Interface).

> Do people still waste time trying to make buffer-overflows slightly less
> damaging rather than just ruling them out?

Yes. Sigh.

Obviously, security is not important enough

a) to justify changing calling standards

b) to justify the sight loss of performance that completely security against buffer overflow requires (see, e.g.
Hardbound and Softbound research by Milo Martin et al, discussed in this newsgroup). (At which point folks will jump in
and say that THEY thought they had explained why this approach will not work.)
 |  Next  |  Last
Pages: 1 2
Prev: Why does Intel favor thin rectangular CPUs?
Next: GPGPU Programming/Architecture