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.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
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.
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