3 ms·

Related to the above, two important concepts to know w.r.t a stack are "Red Zone" and "Guard Pages". Raymond Chen again; Why do we even need to define a red z

Related to the above, two important concepts to know w.r.t a stack are "Red Zone" and "Guard Pages". Raymond Chen again; Why do we even need to define a red zone? Can’t I just use my stack for anything? - https://devblogs.microsoft.com/oldnewthing/20190111-00/?p=100685 https://devblogs.microsoft.com/oldnewthing/20190111-00/?p=10... A closer look at the stack guard page - https://devblogs.microsoft.com/oldnewthing/20220203-00/?p=106215 https://devblogs.microsoft.com/oldnewthing/20220203-00/?p=10...

Joker_vD 2mo ago
I wonder how Linux manages without explicit _chkstk? In my experience, it feels like MAP_GROWSDOWN regions have way more than 1 guard page below its start — I can poke like a megabyte lower than its start, and the kernel will grow the memory region into there just fine.
- inigyou 2mo ago
  It doesn't. This causes the StackClash vulnerability.
  - rramadass 2mo ago
    https://news.ycombinator.com/item?id=49343032 https://news.ycombinator.com/item?id=49343032
- rramadass 2mo ago
  Preventing stack guard-page hopping - https://lwn.net/Articles/725832/ https://lwn.net/Articles/725832/ According to this article, allocation in page sizes with implicit probing is used; Stack clash mitigation in GCC, Part 3 (-fstack-clash-protection option) - https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3# https://developers.redhat.com/blog/2020/05/22/stack-clash-mi...
  - avadodin 2mo ago
    Thank you for the context. But still. You have a desirable performance optimization feature —used in every Linux program— that happens to interfere with a lousy exploit mitigation. No one should ever need more than 64kBs for a stack anyways.
    - Joker_vD 2mo ago
      > No one should ever need more than 64kBs for a stack anyways. Well, if people would stop storing anything except than return addresses on the stack, yeah, probably even 32 KiB of stack would be enough for anyone. It'd also single-handedly stop all kinds of stack-smashing attacks, too: can't overwrite a return address on the stack if nothing stores data on the stack except the CALL/RET instructions. Unfortunately, the current zeitgeist is still to have "writeable stacks" which are only moderately less horrible for the security than "executable stacks".
      - rramadass 2mo ago
        You can probably do this by maintaining two parallel stacks, changes to prologue/epilogue code and runtime startup files.

Joker_vD 2mo ago

I wonder how Linux manages without explicit _chkstk? In my experience, it feels like MAP_GROWSDOWN regions have way more than 1 guard page below its start — I can poke like a megabyte lower than its start, and the kernel will grow the memory region into there just fine.

inigyou 2mo ago
It doesn't. This causes the StackClash vulnerability.
- rramadass 2mo ago
  https://news.ycombinator.com/item?id=49343032 https://news.ycombinator.com/item?id=49343032
rramadass 2mo ago
Preventing stack guard-page hopping - https://lwn.net/Articles/725832/ https://lwn.net/Articles/725832/ According to this article, allocation in page sizes with implicit probing is used; Stack clash mitigation in GCC, Part 3 (-fstack-clash-protection option) - https://developers.redhat.com/blog/2020/05/22/stack-clash-mitigation-in-gcc-part-3# https://developers.redhat.com/blog/2020/05/22/stack-clash-mi...
- avadodin 2mo ago
  Thank you for the context. But still. You have a desirable performance optimization feature —used in every Linux program— that happens to interfere with a lousy exploit mitigation. No one should ever need more than 64kBs for a stack anyways.
  - Joker_vD 2mo ago
    > No one should ever need more than 64kBs for a stack anyways. Well, if people would stop storing anything except than return addresses on the stack, yeah, probably even 32 KiB of stack would be enough for anyone. It'd also single-handedly stop all kinds of stack-smashing attacks, too: can't overwrite a return address on the stack if nothing stores data on the stack except the CALL/RET instructions. Unfortunately, the current zeitgeist is still to have "writeable stacks" which are only moderately less horrible for the security than "executable stacks".
    - rramadass 2mo ago
      You can probably do this by maintaining two parallel stacks, changes to prologue/epilogue code and runtime startup files.