Hacker News new | past | comments | ask | show | jobs | submit login
Understanding Hardware-Enforced Stack Protection (microsoft.com)
24 points by ingve 13 days ago | hide | past | web | favorite | 5 comments

I was thinking about this the other day, wondering why modern RISC machines (like RISC-V). that don't have call/return instructions that hard code stack direction, simply have coding models that grow their stacks upwards - this would avoid most of these sorts of problems

Yeah that’s a very good point.

There may be multiple reasons but a performance reason of which I’m aware is downward stacks are more efficient for allocating aligned memory:

    sp = (sp - size) & align;
That’s only two instructions, with a stack that grows upward:

    sp += size;
    if (sp & (align - 1))
      sp += align - (sp & (align - 1)); 
Which is a few more instructions. Of course you can alleviate this by requiring an alignment invariant in the ABI, which is usually done anyway.

The classical reason why stacks grow downward is because heaps grow upward. This arrangement maximizes the usefulness of the virtual address space in a single-threaded process.

well stacks typically grew downwards even before there were heaps (but not always - Burroughs large systems for example)

Heaps of course can grow downwards

With modern 64-bit address spaces actual running out of space is not an issue (especially since we're dynamically moving around code, heaps and stacks for security reasons anyway)

i’ve often wondered this. but wrt ROP sled, does it matter? instead of overwriting “this” stack frame’s ret address, you’d overwrite the previous. the effect would be seen when your caller returns instead of when you return.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact