4 ms·
How do large stack objects jump over the protected area? Even if the OS allocates so much stack space that the stack pointer overlaps with the heap area, if the
by rambojazz 8y ago
How do large stack objects jump over the protected area? Even if the OS allocates so much stack space that the stack pointer overlaps with the heap area, if the stack is written sequentially I would think that it's going to write to the protected area before it writes to memory beyond it.
EDIT: maybe I got this. Basically, if my stack pointer jumps the protected page and ends up in the heap, I can address prefix[last_pos] without triggering any page fault, thus corrupting memory. Is this correct? I guess guard pages are a very weak protection mechanism, the OS should check the position of the stack pointer at every memory allocation.
- Someone 8y agoYes, that’s correct. For example, if the stack grows downwards (which, AFAIK, is the case on most current architectures): - stack pointer is at S - protected area starts at B, ends at E (with B<E<S) - stack is decreased by something larger than (S-B), making it point somewhere before the start of the protected area Compilers won’t allocate large local variables on the stack, so guard pages work fine for accidental stack overflows, such as when a call stack gets too deep. They also work reasonably well against intentional (by an attacker, not by the programmer who wrote the code) ones, but indeed aren’t perfect. That’s why some compilers have compiler flags that, when allocating a stack variable that they don’t know to be ‘small’ will insert extra code that will hit the protected area, even if the allocation jumps over it.