Re: Smashing the stack

[dholland () EECS HARVARD EDU (David Holland)]

> Some architectures grow the stack "upwards" in memory instead of
> "downwards"; this means that buffer overrun doesn't overwrite existing
> stack frames at all.  Is there a solution for this kind of architecture?
> For that matter, can anyone offhand name such a machine?  I've heard
> rumours about Crays...

HP PA-RISC stacks grow up.

> A good way to stamp out most of these attacks would be to allocate
> automatic variables somewhere on the heap or at least somewhere that
> isn't the stack.  This may cause a performance penalty on CPUs that
> have special optimizations for data at short offsets from a particular
> "stack" register.  This solution may be unreasonable on most real-world
> systems, but if you're designing a system from the ground up this is
> something to think of early on if it genuinely makes no difference in
> terms of performance.

If anyone's designing a new architecture from the ground up they
should build it to have multiple stacks, not "the" stack. Then you put
your automatic storage on one stack, and your call stack on the
other. A third stack would make exception handling much easier, too.

--
   - David A. Holland             |    VINO project home page:
     dholland () eecs harvard edu    | http://www.eecs.harvard.edu/vino