>> 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B