News: 0170263425

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Proposed Linux Patch Allows Disabling CPU Security Mitigations at Build-Time (phoronix.com)

(Saturday February 04, 2023 @11:34AM (EditorDavid) from the patch-possibilities dept.)


Phoronix reports:

> A proposed Linux kernel patch would provide a new Kconfig build time option of "CONFIG_DEFAULT_CPU_MITIGATIONS_OFF" to [1]build an insecure kernel if wanting to avoid the growing list of CPU security mitigations within the kernel and their associated performance overhead.

>

> While risking system security, booting the Linux kernel with the "mitigations=off" option has been popular for avoiding the performance costs of Spectre, Meltdown, and the many other CPU security vulnerabilities that have come to light in recent years. Using mitigations=off allows run-time disabling of the various in-kernel security mitigations for these CPU problems.

>

> A patch proposed this week would provide CONFIG_DEFAULT_CPU_MITIGATIONS_OFF as a Kconfig switch that could optionally be enabled to have the same affect as mitigations=off but to be applied at build-time to avoid having to worry about setting the "mitigations=off" flag.



[1] https://www.phoronix.com/news/Linux-Default-Mitigations-Off



reasoning? (Score:2)

by nickwinlund77 ( 4759293 )

This is dumb. Where are our clean, safe cores? Why are there always compromises with chip and software security? Why can't Intel stay ahead of the curve?

Re: reasoning? (Score:2)

by sirber ( 891722 )

Bugs are found after release.

Re: (Score:2)

by John Allsup ( 987 )

Even if Intel magically found a way to stop the vulnerabilities, there are still millions, if not billions, of Intel chips out there that are vulnerable. on the other hand, many use-cases are not security-sensitive enough to warrant the loss in performance.

Re:reasoning? (Score:4, Informative)

by test321 ( 8891681 )

This option is useful if you compile kernel for machines that are fully run inside the organization, like crunching numbers, training neural networks, control hardware equipment; machines that do not have a user with a web browser or host customer VMs.

Re: (Score:2)

by nickwinlund77 ( 4759293 )

ok thanks for clarifying that. That makes more sense now.

Re: (Score:2)

by test321 ( 8891681 )

But what I would like is to have real-time activation/deactivation of the mitigations, per core and per cgroup. So any core where a browser or a password manager runs must have the the mitigations on, but if the core only run processes that are not controlled by remote users and do not hold any sensitive data (e.g. numerical simulations, gaming) then the mitigations can be off on that core. But I don't know if what I say makes sense, or why they haven't done it yet if it was easy.

Re: reasoning? (Score:1)

by dowhileor ( 7796472 )

Yea, kind of how gpu's were proposed to run. But the register barrier between cpu/gpu runspace was never the priority of userland devs.

Re: (Score:2)

by geekmux ( 1040042 )

> This is dumb. Where are our clean, safe cores? Why are there always compromises with chip and software security? Why can't Intel stay ahead of the curve?

Because you keep assuming this is something they actually want to fix.

That's why.

Not all machines are subject to remote code (Score:2)

by stikves ( 127823 )

This is not for your httpd server, user facing machines, or even internal services. This is more for render farms, compute clusters, and other dedicated machines where 1% additional performance is measured in millions of dollars per year.

If you only have a single known app, read only Linux image, probably installed remotely using puppet/maas or something similar, you'd have less worries about malicious code. As, when Blender itself is compromised, you have already lost, anyway.

"The lesser of two evils -- is evil."
-- Seymour (Sy) Leon