Re: Why are variables stored on the stack?


"CJ" <cj@xxxxxxxxxx> wrote in message
news:slrnftn8uu.3lg.nospam@xxxxxxxxxxxxxxxxx
Thanks for all the replies, this is an interesting discussion.

Here are a couple of points that occur to me:

1) Buffer overflows are a more serious security problem on the stack
than on the heap, because the program counter is stored on the stack and
not the heap, so that a malicious stack overflow can execute arbitrary
code. The heap is used for data exclusively, which is what I meant by
"separate data from executable code".

Even if a buffer on the heap overflows, the worst that can happen is
some (probably insignificant) data corruption. Since malloc() generally
allocates space in powers of 2, often an off-by-one error or similar
won't overwrite anything anyway, but will just land in the gap between
the end of the buffer and the next power of 2.

2) I believe the argument about it being more efficient to use the stack
than the heap is spurious - if I recall, both are O(N) data structures.

The heap is a fragmented resource and requires a function call to allocate
and deallocate.

The stack, by it's nature, is unfragmented and allocation and deallocation
is very fast, especially when hardware assisted.

To address your other concerns, then yes it might be a good idea to have a
compiler option to put auto-data on the heap, to avoid accidental or
malicious overwrite of critical data. But your applications might run 10-100
x slower if they do lots of function calls.

But in practice, if there was such an option, the compiler would simply
create a separate, linear data-stack with a software stack pointer. And
performance would be little affected. So your idea is a good one.

--
Bart




.

Relevant Pages

  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >> All of these would put their data on the heap, not on the stack. ... you're trying to guard against deliberate attacks that take advantage ... Buffer overflow attacks only work if the buffer is in a part of memory that ...
    (comp.security.misc)
  • Re: Privilege-escalation attacks on NT-based Windows are unfixable
    ... >> All of these would put their data on the heap, not on the stack. ... you're trying to guard against deliberate attacks that take advantage ... Buffer overflow attacks only work if the buffer is in a part of memory that ...
    (comp.os.ms-windows.nt.admin.security)
  • Re: Why are variables stored on the stack?
    ... Buffer overflows are a more serious security problem on the stack ... not the heap, so that a malicious stack overflow can execute arbitrary ...
    (comp.lang.c)
  • Re: How does managed code work?
    ... Does it work the same way as the native stack with a frame pointer that is the head of a linked list of stack frames where each time we enter a function we create a new stack frame in which new variables are pushed and each time we exit a function the entire stack frame is popped? ... Can someone point me to a discussion of the managed heap? ... How does it prevent memory leaks that occur in COM when two objects reference each other and keep the others reference count nonzero? ... Because objects don't go out of scope, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why are variables stored on the stack?
    ... Buffer overflows are a more serious security problem on the stack ... than on the heap, because the program counter is stored on the stack ...
    (comp.lang.c)