Linux 5.13 Poised To Allow Randomizing Kernel Stack Offset At Each System Call

[phoronix]

Phoronix: Linux 5.13 Poised To Allow Randomizing Kernel Stack Offset At Each System Call

The ability to randomize the kernel stack offset at each system call looks like it will land for the upcoming Linux 5.13 cycle. This optional feature makes it much more difficult to carry out stack-based attacks on the Linux kernel...

https://www.phoronix.com/scan.php?page=news_item&px=Radomize-Stack-Syscall-5.13

[kylew77]

Forgive me for the noobish question but how does this compare to what OpenBSD does with relinking the kernel after each boot? Is this the same except on steroids where it does it after every system call practically or is this something entirely different?

[Alex/AT]

@kylew77
It's not about randomizing kernel code locations and/or contents.
It's about randomizing the location in memory where kernel code will store volatile temporary data (stack) like return points and arguments/variables on subroutine calls during the very syscall (and so each new syscall gets random stack location assigned making stack based attacks / attack calculations unable to determine where exactly stuff should land).

[s_j_newbury]

I wonder if we wouldn't be better of without all the address randomisation and shouldn't instead make debugging potential vulnerabilities easier making the attack surface smaller by fixing bugs instead of hiding them? A lot of efficiency and potential optimisations are also sacrificed here with the full suite of obfuscation techinques.

[yoshi314]

we would not.

because debugging and fixing bugs you know about can only take you so far. you have to prepare for the unknown potential problems as well, to an extent.

there are many security issues that stem from hardware faults or unexpected behaviour of the hardware. perfect code won't ever protect you from them. nor from ones that are caused by misbehaving userspace apps.

having multiple layers of security is better that having one and hoping for the best. and perfectly secure code that actually does something may exist on paper but not in reality. an unexpected glitch, quirk of one of the chips, or a person/device randomly shorting circuits on the mainboard is not something you can plan for.

[LightBit]

I wonder if we wouldn't be better of without all the address randomisation and shouldn't instead make debugging potential vulnerabilities easier making the attack surface smaller by fixing bugs instead of hiding them? A lot of efficiency and potential optimisations are also sacrificed here with the full suite of obfuscation techinques.

Sure, we just need to write perfect code.