Proposed Linux Patch Allows Disabling CPU Security Mitigations at Build-Time (phoronix.com) 43
Phoronix reports:
A proposed Linux kernel patch would provide a new Kconfig build time option of "CONFIG_DEFAULT_CPU_MITIGATIONS_OFF" to 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.
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.
reasoning? (Score:1)
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:3)
Re:reasoning? (Score:5, Informative)
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: (Score:3)
Re:reasoning? (Score:5, Insightful)
many use-cases are not security-sensitive enough to warrant the loss in performance.
I challenge how far you went with that statement. I would say nearly all use cases beyond some specific corporate / government use cases are not security sensitive enough. Speculative execution attacks are hard to execute in any meaningful way, and by meaningful I mean allowing an attacker to get anything useful out of the system. Thus far the only examples of it working have been demonstrated in environments where the attacker knows everything about the system.
The reality is, why would you go to the effort for a normal person? I could target you, put the effort in, or I could simply a password reset request to 1million email addresses with a link to www.bankofamreica.com and be content with the fact that there are enough careless suckers out there to make this far more viable.
On the other hand if you're a foreign agent and you need something from a government computer you may put the effort in and a spectre mitigation may be worthwhile.
Re:reasoning? (Score:5, Insightful)
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)
ok thanks for clarifying that. That makes more sense now.
Re: (Score:2)
backend storage systems as well some software raid (Score:2)
backend storage systems as well some software raid systems / systems with lot's of pci-e storage do have some CPU hit for that.
Re: (Score:2)
Re: (Score:2)
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)
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)
That could be cool.
But it would be a lot harder to code that way, where a simple switch to turn it on and off would be quite simple.
Also, turning it on and off on a per-core basis and making sure that certain security-sensitive processes only run on the cores with it off might not work if the issues involve a cache or memory management unit or something else that may be shared between cores.
Allowing switching on or off the mitigations (Score:2)
Then the hackers will figure out how to switch off the mitigations, do their dirty work, and then switch them on and hum "dum-de-dee-dee-dum" and give a real innocent look?
Re: (Score:3)
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.
Re: (Score:2)
Re: (Score:3)
Why are there always compromises with chip and software security?
Why do you not live in a bank vault? Why do you trust your horrendously insecure house with windows that can easily be defeated with a brick while you're not home? When you answer that you'll have the answer as to why we compromise on security.
Why can't Intel stay ahead of the curve?
What's intel got to do with this? Speculative execution attacks have been demonstrated on every CPU architecture by now. Just because the first and most prominent was an Intel issue doesn't mean that these kinds of compromises aren't in AMD, ARM, or POWER either.
Not all machines are subject to remote code (Score:5, Insightful)
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.
Re: (Score:2)
Isn't it that those CPU bugs can only be exploited if the attacker can run code on the server? This would apply to hypervisors with customer VMs and hosting with customer code, but, say, for a video streaming server it may not be needed. If the video streaming software has a remote code execution bug, then the attacker could probably do everything anyway.
Same goes for a Linux router - it may have some remote code execution bug, but then you would have lost anyway.
Ar recent CPUs still affected by this? (Score:3)
Re: Ar recent CPUs still affected by this? (Score:1)
Re:Ar recent CPUs still affected by this? (Score:5, Interesting)
Would correcting them break compatibility?
Not compatibility, speed. The vulnerabilities exist solely due to how modern CPUs implement some performance improvement measures. Some specific cases such as Spectre-V2 have been mitigated in hardware already as this was possible without affecting performance. But speculative execution attacks vectors are wide and varied and many mitigations proposed range from high single digit to multi-digit performance costs.
Given how hard these attacks are to gain anything meaningful (other than a small dump of a random memory area) it's simply not a security risk worthwhile resolving in a way that impacts performance for the overwhelming majority of use cases. And for everyone else, there's software mitigations, which in some ways perform close to some of the proposed hardware ones.
Re: Ar recent CPUs still affected by this? (Score:2)
The original problems are fixed, but they keep finding variations and different issues. Until spectre/meltdown, people werenâ(TM)t really looking into your CPU hardware for bugs, plenty of low hanging fruit in the OS. Besides that, some of the issues need to change how the OS interacts with the CPU and it simply takes a long time for these issues to be worked out, Intel is currently building the chips that are about 2 generations further, whatever is rolling from the factory floor today is a design tha
Call me a curmudgeon... (Score:2)
... but I'm still not convinced that these CPU vulnerabilities are exploitable in real-world scenarios. Even right now on my mostly idle PC, Windows 10 Task Manager is saying that I have 174 processes (15 of which are Brave browser). Anti-virus, Windows Update, 8000 various Windows services, Steam: It seems difficult to imagine malicious software could actually extract particular values when there is so much context switching going on.
These seem like the types of vulnerabilities that are at the proof of
Re: (Score:2)
Re: (Score:3)
If those processes are mostly idle, they aren't being context-switched in and out much, if at all. Processes only get scheduled on the CPU when they're actually in a runnable
Re: (Score:2)
Well, that's the reason why there should be options to disable it. For th
I'd see this trend mprove with more options (Score:2)
Not all applications need high security, and not all applications need high accuracy.
I see this trend of having a switch for flaw mitigation expand to arithmetic and maybe one day to logic if we can create algorithms that can assume the CPU will not always run the code accurately.
Maybe we would be able to trade accuracy for speed or lesser power consumption.
I take as an example when we humans type words on a keyboard. We accept a few errors to type faster, even if we have to go back and correct from time to
Why? (Score:2)
I don't understand the reasoning. If you can already disable the mitigations at run-time, what's the point of disabling them at build time? Just put mitigations=off in your standard image and leave it at that.
Re: (Score:2)
How much space do the mitigations take? A few hundred bytes? Couple of kB?
Re: (Score:2)
The cost is some dozens of bytes, times the number of times every affected instruction appears. Which is obviously not trivial from the straight linear performance perspective as it is more instructions to execute, but also i
Re: (Score:2)
OK, thank you. That's a pretty good explanation.
Re: (Score:2)
Better question, why not? The Linux kernel is built with a very long list of highly modular and customisable options. It would seem completely bizarre to not include this as a build option.
Re: (Score:2)
In this day and age, it feels strange to computer users when the software leaves them the choice to be in total control and be configured in non-corporate-approved ways.
How about at boot time? (Score:2)
How about disabling the mitigations at boot time without rebuilding the kernel?
Like another commenter said, a significant number of servers don't need to worry about SPECTRE and other vulnerabilities and could use the extra 3%-10% boost in performance.