Re: use alternate stack, or the heap for local function variables

[Danilo Segan <dsegan at gmx dot net>]

Keld JÃrn Simonsen <keld@dkuug.dk> writes:
>
> If the stack with the parameters and the function return code is
> separated from the local function data, then there is no way for a
> buffer overflow to overwrite the return address, and thus there is no
> way for the intruder to get into the instruction execution flow.
>

This is something that should perhaps be in the kernel, at least IMHO.
I know that at least Intel 32-bit architecture supports defining
segments for data and code separately, and the big problem here is
that all kernels that I know of map each of them to the same address
space (i.e. 0--4GB).  Since code segment on Intel processors is not
writeable (if I remember correctly), separating these segments would
enforce (in hardware) correct policy on all users.

This is how I imagined solving buffer overflows as well, but I'm a
real amateur, and never really gave it any thought if this could be
solved without noticeable performance penalty.  Anyhow, the hardest
thing to come up with here is the policy, and of course,
modifications to the compiler because something there is probably
based on the assumptions of SS, DS and CS all pointing at the same
memory.

Anyhow, this would surely reduce portability, and it's really not
relevant to the libc-alpha list (and I guess Ulrich Drepper is now
going to hate me for answering this -- I promise no more this kind of
talk here :).

Cheers,
Danilo