Benchmarking The Performance Impact Of Linux 5.15's Newest Protection Around Side Channel Attacks

[phoronix]

Phoronix: Benchmarking The Performance Impact Of Linux 5.15's Newest Protection Around Side Channel Attacks

With the in-development Linux 5.15 kernel there is a new option for further protecting the kernel around side channel attacks and information leakage. Enabling the option will ensure that any caller-used register contents are zeroed prior to returning from a function. While the reported performance cost is said to be small, I decided to run some benchmarks when toggling this new Kconfig hardening option.

https://www.phoronix.com/vr.php?view=30504

[milkylainen]

Not sure, but I would expect aarch64 to take a bigger hit.

[tildearrow]

Typo:

The option also enables the kernel image by less than 1% on AArch64

What?

But for real-world workloads, any performnace impact of ZERO_CALL_USED_REGS is expected to be minimal.

[binarybanana]

mitigations=off

[cjcox]

It's just a 1% performance hit. (100 mitigations later) Why does my machine suck?

[qarium]

It's just a 1% performance hit. (100 mitigations later) Why does my machine suck?

in reality these companies like intel are criminals they abuse a vaccum of goverment regulations in this field.

we really need laws against this... laws like this: if there is a security hole the hardware companies like intel need to fix this in hardware or else they are not allowed to sell hardware anymore. also we need a law to make sure for old hardware no software are allowed to be without mitigations. means every system need to be secure if a company sells it or else they are not allowed to bring this to market. (the user can hurt themself by deactivate the mitigation.)
if intel reject to make security hardware (because they claim a software fix does it) this company then should be banned to sell hardware.
yes i know some hardware fix would hurt performance but in reality this is only short time problem and on the long run it would be much better. we finally have to accept that selling cpus and gpus with hardware security holes is in fact a crime.

the law should really be like this: make it save and secure in hardware or else you are not allowed to sell anything.

[hoohoo]

Michael , you wrote "...reduce the number of ROP gadgets in a kernel image by around 20% and eliminate simple "write-what-where" gadgets"

What is a gadget in this context?

Thanks!

[linner]

When, if ever, will we be able to buy hardware that isn't flawed out of the box? These issues are big enough that way back at the start of this the manufacturers should have been forced to go back to the drawing board. Instead we get continuous new releases of products that are impossible to secure.

[binarybanana]

It's probably impossible be to make a fast CPU with OoO, speculative execution, caches and and all that good stuff without opening it up to side channels. In the end you're dealing with physics and can just measure things like voltage, current and power/temperature to draw conclusions about what is being computed.

None of these "security holes" matter for the (even not-so) average desktop/workstation user. It's mostly big multi-user systems that are affected. Some say stuff like Spectre/Meltdown can be exploited from a browser, but I couldn't get Google's demo[0] to work in Firefox, even with mitigations=off and as old a BIOS I can flash. If that's the best they can do I'm not very worried. Things are different when you host dozens of user's VMs on a machine, but I don't.

[0]: https://leaky.page/

[PerformanceExpert]

Not sure, but I would expect aarch64 to take a bigger hit.

Indeed. It depends on what setting is actually used (gpr-used or arg-used?), but having lots of registers means you also spend more time zeroing them. If this terrible idea takes off in distros as well, most CPU will have to add special RETCLR instructions which clear registers on function exit.