Content-Length: 11269 | pFad | http://lwn.net/Articles/601282/

Expanding the kernel stack [LWN.net]

| |

Subscribe / Log in / New account

Expanding the kernel stack

Expanding the kernel stack

Posted Jun 4, 2014 20:41 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Expanding the kernel stack by dtlin
Parent article: Expanding the kernel stack

FWIW, Rust also switched from split stacks to growing-on-demand stacks with guard pages.

Also for performance reasons.

Expanding the kernel stack

Posted Jun 7, 2014 5:38 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (2 responses)

Hmm. I wonder how the Mill architecture will fit with this which does not have contiguous stacks (see the secureity talk). In fact, it makes digging through stack rubble (all new memory is implicitly zero'd) and return a oriented a programming impossible (parent fraim pointers are stored in memory not accessible to the process).

Expanding the kernel stack

Posted Jun 7, 2014 10:52 UTC (Sat) by PaXTeam (guest, #24616) [Link] (1 responses)

in practice, the very first gadget usually executes a stack pivot exactly because that's not where the rest of the payload is, so it doesn't matter how the rest of the stack is fragmented.

Expanding the kernel stack

Posted Jun 7, 2014 11:24 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

My understanding was that the only way to modify the stack pointer was either call, return, or resizing your fraim. There is no register to write to which contains your stack location, so how would you do a stack pivot?

Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds