|
|
Subscribe / Log in / New account

Per-system-call kernel-stack offset randomization

Per-system-call kernel-stack offset randomization

Posted Mar 30, 2020 3:05 UTC (Mon) by gutschke (subscriber, #27910)
In reply to: Per-system-call kernel-stack offset randomization by Paf
Parent article: Per-system-call kernel-stack offset randomization

The point of this patch is that instead of having a single base address for the system call stack, there should be 32 or 64 distinct addresses (depending on architecture). This makes it impossible for an attacker to reliably guess addresses on the stack. And hopefully, that will cause (some) attacks to fail with some sort of kernel crash. Of course, if there is no crash, an attacker can just keep guessing and eventually they'll get lucky.

Randomization happens by the virtue of random amounts of data being allocated on the stack. This happens right at the point of the transition from user space to kernel space.

But alloca() knows about the x86 ABI. And the ABI requires that stack frames are aligned in 16 byte increments. That's needed, because some CPU instructions want aligned data (I believe this mostly affects SSE instructions). The compiler assumes that stacks are always aligned when the program starts (or in this case, when the system call starts executing in the kernel) and then makes sure the necessary padding is added whenever a function call is made.

There really isn't any unused memory that is readily available for other purposes.


to post comments


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