Linux's New "randomize_kstack_offset" Security Feature Having Minimal Performance Impact
Of the many new features in Linux 5.13 one of the prominent security features is the ability to randomize the kernel stack offset at each system call. With Linux 5.13 stable imminent, here are some performance benchmarks of the impact from enabling this security feature.
Linux 5.13 has the ability to randomize the kernel stack offset per system call to make it more difficult for attackers to achieve stack-based attacks on the kernel for those exploits relying on stack determinism. This mainline kernel feature was inspired by PaX's existing "RANDKSTACK" while the actual implementation differs.
With the initially supported architectures of x86/x86_64/AArch64, the option to randomize the kernel stack offset for each syscall can be configured via the randomize_kstack_offset= boot parameter. The default value can be configured by distribution vendors and other kernel builders with the CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT Kconfig option.
A basic synthetic benchmark looking at the system call performance overhead of randomize_kstack_offset put it at around 1%. The past few days I've been running dozens of benchmarks on a Lenovo laptop with Ryzen 5 5500U processor looking at the synthetic and real-world performance cost to having randomize_kstack_offset enabled and then disabled using a near-final Linux 5.13 kernel build.
The basic ctx_clock test for measuring the number of cycles to perform a context switch saw the greatest impact of any of the benchmarks run... Granted, just 20 cycles and far lower relative impact to the context switching performance than what we've seen out of some security mitigations.
Of real-world workloads tested, Redis saw the greatest impact, which came out to being about 2% slower with the kernel stack offset randomization per system call being enabled.
Across dozens of other synthetic and real-world benchmarks, the randomize_kstack_offset amounted to 1% or less impact and in many cases no measurable difference at all.
So for those concerned about system security, the performance impact doesn't appear to be too great at all when running with randomize_kstack_offset=1 on a modest Ryzen 5 laptop. This jives with other tests earlier in the cycle and of the upstream expectations of 1% or less overhead.
Linux 5.13 has the ability to randomize the kernel stack offset per system call to make it more difficult for attackers to achieve stack-based attacks on the kernel for those exploits relying on stack determinism. This mainline kernel feature was inspired by PaX's existing "RANDKSTACK" while the actual implementation differs.
With the initially supported architectures of x86/x86_64/AArch64, the option to randomize the kernel stack offset for each syscall can be configured via the randomize_kstack_offset= boot parameter. The default value can be configured by distribution vendors and other kernel builders with the CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT Kconfig option.
A basic synthetic benchmark looking at the system call performance overhead of randomize_kstack_offset put it at around 1%. The past few days I've been running dozens of benchmarks on a Lenovo laptop with Ryzen 5 5500U processor looking at the synthetic and real-world performance cost to having randomize_kstack_offset enabled and then disabled using a near-final Linux 5.13 kernel build.
The basic ctx_clock test for measuring the number of cycles to perform a context switch saw the greatest impact of any of the benchmarks run... Granted, just 20 cycles and far lower relative impact to the context switching performance than what we've seen out of some security mitigations.
Of real-world workloads tested, Redis saw the greatest impact, which came out to being about 2% slower with the kernel stack offset randomization per system call being enabled.
Across dozens of other synthetic and real-world benchmarks, the randomize_kstack_offset amounted to 1% or less impact and in many cases no measurable difference at all.
So for those concerned about system security, the performance impact doesn't appear to be too great at all when running with randomize_kstack_offset=1 on a modest Ryzen 5 laptop. This jives with other tests earlier in the cycle and of the upstream expectations of 1% or less overhead.
20 Comments