Linux Kernel Gets Another Option To Disable Spectre Mitigations (zdnet.com) 50
Despite being more than one year old, the Meltdown or Spectre vulnerabilities have remained a theoretical threat, and no malware strain or threat actor has ever used any in a real-world attack. Over the course of the last year, system and network administrators have called on the Linux project for options to disable these protections. A report adds: Many argued that the threat is theoretical and could easily be mitigated with proper perimeter defenses, in some scenarios. Even Linus Torvalds has called for a slowdown in the deployment of some performance-hitting Spectre mitigations. The Linux kernel team has reacted positively towards these requests and has been slowly adding controls to disable some of the more problematic mitigations.
[...] The latest effort to have mitigations turned off -- and stay down -- is the addition of the PR_SPEC_DISABLE_NOEXEC control bit to the Linux kernel. This bit will prevent child processes from starting in a state where the protections for Spectre v4 are still activated, despite being deactivated in the parent process.
[...] The latest effort to have mitigations turned off -- and stay down -- is the addition of the PR_SPEC_DISABLE_NOEXEC control bit to the Linux kernel. This bit will prevent child processes from starting in a state where the protections for Spectre v4 are still activated, despite being deactivated in the parent process.
Re: (Score:2)
I see that there's a difference between the problem and if that is actually a case where it would be a problem in your specific use of the server.
Retrospective enforcement (Score:2)
Here's another possible way to work this in a low risk low hazard environment that makes the most sense to me.
1. Don't prevent it or impede it in any way.
2. Except, periodically poll the system state with a hypervisor that looks for evidence of timing based attacks. it could also scoop up row hammer attacks in the same way.
3. Freeze the processes and report them to the admin, and if you opt-in, report suspect behavior with code snippets or fingerprints to a central database
Re: (Score:2)
That implies that the hypervisor doing the monitoring is in the CPU scheduler and running on a core all the time. Wouldn't that introduce exactly the same performance penalty as just disabling the branch prediction in first place?
Never exploited? (Score:2, Interesting)
That comment is a total red flag. Seems a little bit presumptuous.
Never exploited on a honeypot maybe, or never with with a exe.
The option should be at least available, but the claim it's never been used may be bs
Re: (Score:2)
He's probably a doctor. They always claim that something is "incurable". In all of the universe forever. When really, they just haven't heard of the cure / read the research paper yet.
In that case I'm eagerly awaiting the research paper that contains the cure for stupidity.
Re: (Score:3)
but the claim it's never been used may be bs
It may be BS, but it suits Occams Razor quite well. It's a complicated attack requiring knowledge of the target so intimate that many countless easier attacks are available which could achieve a similar goal.
Sounds like a good idea. (Score:2)
Spectre etc are dreadful if you're running a server with secrets on. Things that turn remote exploits into local ones are bad.
I don't want the slowdowns on compute machines though. It's not like there's remote access from anything untrusted anyway so the security holes aren't an issue.
Re:Sounds like a good idea. (Score:5, Insightful)
I don't want the slowdowns on compute machines though. It's not like there's remote access from anything untrusted anyway so the security holes aren't an issue.
This is what's so great about Linux, or for that matter *BSD. Sane defaults, but you control your computer. That's worth a whole lot of hassle.
Re:Sounds like a good idea. (Score:5, Insightful)
This is what's so great about Linux, or for that matter *BSD. Sane defaults, but you control your computer. That's worth a whole lot of hassle.
For better and for worse, the reality these days is that most companies are migrating to cloud and devops, where you don't control your own computer, and don't have admins that understand the underlying architectures and the nitty gritty bits of how to configure a kernel or why.
Magic black boxes is the new standard, and control has become a negative word.
Re: (Score:3)
Problem is, cloud providers only deliver on their promise when they're big...
Protect your server, not your video encoder (Score:5, Insightful)
This is about process-level options. Your workstation or server might have a server process that is network accessible, and another proces that is CPU-intensive. You probably do want to enable protection for your file sharing server process or IMAP; you probably want your ray tracer to run at full speed.
An example I've worked with many times is a web server that has videos in several bitrates or formats. In the background, it transcodes videos from whatever format they are in when they are uploaded. That's CPU intensive. You'd want protections on the web server daemon, probably wouldn't want to slow down the transcoding process by adding protections there.
While we're at it (Score:2)
Let's just forego getting vaccinations for any kid because kid's don't get sick from measles or other things any more.
Re: (Score:2, Troll)
(Forego still means precede, even though so many incorrectly use it when meaning forgo.)
I gladly advocate forgoing vaccinations for endemic and childhood diseases, because the vaccines are so effective. They reduce culling, and long term cause harm to humanity by saving individual children.
New harmful or detrimental mutations in the human genome that in themselves are not enough to kill someone, but in combination with diseases like measles have a statistically significant higher morbidity are allowed to s
Re: (Score:2)
It doesn't matter to the bugs that you survived a measles attack due to you being vaccinated or due to having superior genes.
This is incorrect. If you've had measles, your immune system is a lot more hardened than with vaccines. If you've been vaccinated, you need booster vaccines, but if you've had measles, you get a fever instantly if you get a vaccine, as your immune system goes into full attack mode. It won't just attack that one strain either, but anything that's close. The weaker "attack" of the disabled pathogens in a vaccine just triggers the immune system "enough" to protect you - not enough to put it in defcon 1.
The
Re: (Score:3)
False equivalency. There are other mitigation available that avoid Spectre and Meltdown, such as not letting people run code on your computer.
Claiming no malware uses these bugs is hilarious (Score:2)
The thing with Spectre and Meltdown is that there is no need to alter the software on the (virtual) CPU cores the victim uses.
Re: (Score:2)
Do people seriously expect malware authors to tout: "Hey look, we just used Spectre successfully and extracted a thousand private keys from software that ran on the same physical cloud servers than our malware!"...?
No, people rely on the large security industry which analyses malware in detail to determine how it works and have identified that no known strains of Malware use this attack.
No surprise really either, it's not like this can be packaged in a general purpose attack. To pull this off in any meaningful way requires knowledge of the target detailed enough that there are easier attack vectors available.
You may be laughing, but no one else is.
Spectre/Meltdown's target is limited (Score:4, Insightful)
It is only of interest if you are allowing any user to execute random code. Eg. desktops (JavaScript and the like) and cloud/virtual servers MAY be affected by it. But for the vast majority of servers and environments, if these bugs are exploited, you typically have bigger issues to fix.
Re: (Score:2)
I disagree. Due to the actual attack vector executing random code won't get you much joy at all. Issuing *targeted* code for a specific machine which you know a lot about may net you something useful. As a result, the random desktop machine isn't really at risk at all. Virtual servers however are as by their nature you've given a customer a wide scope to execute code within their OS.