Slashdot Mirror
Linux Kernel Gets Another Option To Disable Spectre Mitigations (zdnet.com)
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.
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
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.
SJW n. One who posts facts.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Let's just forego getting vaccinations for any kid because kid's don't get sick from measles or other things any more.
Take the cheese to sickbay, the doctor should see it as soon as possible - B'Elanna Torres, "Learning Curve"
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
Some drink at the fountain of knowledge. Others just gargle.
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.
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!"...?
The thing with Spectre and Meltdown is that there is no need to alter the software on the (virtual) CPU cores the victim uses.
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.
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.
Custom electronics and digital signage for your business: www.evcircuits.com
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.