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.

9 of 50 comments (clear)

  1. Never exploited? by Anonymous Coward · · 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

    1. Re:Never exploited? by thegarbz · · Score: 2

      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.

  2. Sounds like a good idea. by serviscope_minor · · 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.

    --
    SJW n. One who posts facts.
    1. Re:Sounds like a good idea. by drinkypoo · · Score: 4, 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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:Sounds like a good idea. by arth1 · · Score: 4, 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.

    3. Re: Sounds like a good idea. by drinkypoo · · Score: 2

      Problem is, cloud providers only deliver on their promise when they're big...

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  3. Protect your server, not your video encoder by raymorris · · 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.

  4. Spectre/Meltdown's target is limited by guruevi · · Score: 3, 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.

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  5. Re:While we're at it by thegarbz · · Score: 2

    False equivalency. There are other mitigation available that avoid Spectre and Meltdown, such as not letting people run code on your computer.