Also, Multics
stacks grow upward -- great for protection against
buffer overrun attacks, but a pain in a modern architecture.
Sorry, I don't
follow that? Why does the stack growth direction make
a difference? It's just a convention, isn't it, which direction is
'push' and which is 'pop'?
Well, some architectures have autodecrement move-to-memory and
autoincrement move-from-memory, but not autoincrement move-to-memory or
autodecrement move-from-memory. The Super-H is an example; I don't
know whether x86 is another.
As for buffer overruns, the point there is that a buffer overrun
clobbers memory addressed higher than the buffer. If the stack grows
down, this can overwrite stack frames and/or callers' locals. If the
stack grows up, all it can overwrite is locals for the current frame
and unused stack space.
Actually, it might be interesting to do a VAX OS that used P1 for
program text and data and P0 for an upwards-growing stack. (It'd mean
not using the VAX stack instructions, since they have a
downward-growing mindset wired into them, but the VAX _does_ allow
mixing either kind of auto-modify with either direction of data move,
so that would be a minor annoyance at worst.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B