Stories
Slash Boxes
Comments

SoylentNews is people

posted by chromas on Monday October 14 2019, @07:54AM   Printer-friendly
from the pedal-to-the-metal dept.

HOWTO make Linux run blazing fast (again) on Intel CPUs

It's just been one security disaster after another for Intel the last few years. Meltdown, Spectre variant after variant and this week the "Microarchitectural Data Sampling" aka Zombieload attack have all required performance-degrading fixes and workarounds. There is no way around turning hyperthreading off to be safe from MDS/Zombieload and this is a rather high performance-price to pay. So what if you don't want to?

[...] If you're not into currency trading or high finance or military contracting or anything of that nature and you'd just like to get maximum performance for your Steam games then adding this is simple switch to your kernel parameters will leave you wide open to all the security risks for maximum excitement and squeeze back every bit of performance you used to get from your Intel CPU:

mitigations=off

If you are using a kernel older than 5.1.13 then you should use this rather long one-liner instead:

noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off

Add either mitigations=off or that long one-liner to your /etc/sysconfig/grub and re-generate grub's configuration file with grub2-mkconfig (your distributions procedure will vary) and you're all set. Do note that the latest stable branch kernels (4.14.x, 4.19.x) do have mitigations=off so that alone is enough on kernels newer than 5.1.13 and later versions of stable branch kernels such as 4.19.60+.

[...] Intel CPUs are not alone in having some security issues. There are problems with other CPUs too. The mitigations=off can be used on any CPU but what it does, if anything, will depend on what CPU you are using. It can be used to slightly increase performance on Intel, AMD, ARM and even PowerPC architectures.

[...] The performance gained by disabling workarounds for the mostly Intel CPU security flaws are not all that impressive in all workloads. The reason is that the most performance-hampering measure required to safely use a Intel CPU is to disable SMT (HyperThreading). Doing so crushes performance in a really noticeable way, so much so that the Linux kernel developers decided to leave SMT enabled by default (unlike some *BSD variants who do disable SMT). Newer Linux kernels will by default use mds=full and not the safer mds=full,nosmt parameter which banks and financial institutions should be using. There is a different between default performance and performance with mitigations=off but it is nowhere near as large as the difference between mitigations=off and mds=full,nosmt.


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 3, Informative) by fustakrakich on Monday October 14 2019, @08:11AM (1 child)

    by fustakrakich (6150) on Monday October 14 2019, @08:11AM (#906866) Journal

    Put that one liner in /etc/lilo.conf

    Don't forget to run lilo

    --
    La politica e i criminali sono la stessa cosa..
    • (Score: 2) by DannyB on Tuesday October 15 2019, @02:47PM

      by DannyB (5839) Subscriber Badge on Tuesday October 15 2019, @02:47PM (#907382) Journal

      That one liner

      mitigations=off

      should be modded funny (fortune file) not useful (lilo.conf).

      Intel Management Engine laughs at your mitigations=off.

      --
      People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 3, Insightful) by J_Darnley on Monday October 14 2019, @08:23AM (3 children)

    by J_Darnley (5679) on Monday October 14 2019, @08:23AM (#906870)

    If you're not running untrusted code, such as javascript or VMs, then there is little point in those hurtful mitigations. I acknowledge that "trusted" code varies from person to person so only you can decide.

    • (Score: 1, Informative) by Anonymous Coward on Monday October 14 2019, @08:40AM

      by Anonymous Coward on Monday October 14 2019, @08:40AM (#906874)

      Untrusted code = networking code

      Supercomputers aren't running these mitigations. Places like AWS are.

    • (Score: 3, Interesting) by hwertz on Monday October 14 2019, @04:55PM

      by hwertz (8141) on Monday October 14 2019, @04:55PM (#907023)

      "If you're not running untrusted code, such as javascript or VMs"
      And even if you're running javascript, the browsers mitigated this problem a while back; quite simply, all these flaws involve priming the cache and measuring the tiny timing difference from having data already in cache versus not. Quite simply the browsers have made their formerly nano-second accurate timer methods round to the nearest some length of time, and added jitter... (the accuracy limit apparently from what I read ranges between 0.02ms and 1ms depending on the browser.)

    • (Score: 2) by driverless on Monday October 14 2019, @09:55PM

      by driverless (4770) on Monday October 14 2019, @09:55PM (#907135)

      That was my response as well. The comment:

      If you're not into currency trading or high finance or military contracting or anything of that nature

      should be:

      If you're not hosting some random bad guy's malware in another VM

      While it makes sense to have it in remote mainframe^H^H^H^Hcloud computing where you're sharing the mainfr... sorry, cloud thing with who knows what malware, it's pointless on personal machines where all it does is slow things down for no purpose.

  • (Score: 3, Informative) by Anonymous Coward on Monday October 14 2019, @09:09AM (5 children)

    by Anonymous Coward on Monday October 14 2019, @09:09AM (#906878)

    L1TF is really only a major factor for people who are worried that a VM might attack their host, so basically, cloud providers. Even so, you can mitigate this by pinning both threads of the same core to the same VM.
    RIDL is a little foggier. It allows a process to steal data from another process running on the other thread of the same core. It seems to me that the OS could mitigate this by only allowing processes to share the core with other processes of similar privilege (same owner, for example, on Linux) and not allowing the OS kernel to share a core with user-space. This would cause minimal performance loss in most situations (certainly compared to disabling HT entirely), as on a typical desktop you do not frequently have multiple CPU-intensive processes running under different users.
    Despite reviewing the documentation here [kernel.org], here [redhat.com], and here [intel.com], I'm not sure if this would actually work or, if so, if either Linux or Windows implements such a mitigation.

    • (Score: 1, Insightful) by Anonymous Coward on Monday October 14 2019, @09:29AM (4 children)

      by Anonymous Coward on Monday October 14 2019, @09:29AM (#906880)

      One way, the most certain way, is to stop running Intel silicon. I have, for the most part, and Linux runs much better. It is not enough to stop using the Win of WinTel, one must also stop using the Intel. Not all backdoors are software. So now I am more and more looking at ARM, since it has become obvious that Micro$erf is incapable of porting to any other architecture than x86. And I say this as one who started out using x88. Take off and nuke them from orbit. It is the only way to be sure.

      • (Score: 2, Funny) by Anonymous Coward on Monday October 14 2019, @09:36AM (1 child)

        by Anonymous Coward on Monday October 14 2019, @09:36AM (#906881)

        One way, the most certain way, is to stop running Intel silicon

        You mean if one takes a hammer on all the chips marked Intel on one's computer, the computer will run faster? Just asking for, you know, a friend.

        • (Score: 3, Funny) by DECbot on Monday October 14 2019, @06:41PM

          by DECbot (832) on Monday October 14 2019, @06:41PM (#907084) Journal

          No, but it will be more secure.

          --
          cats~$ sudo chown -R us /home/base
      • (Score: 2) by hendrikboom on Tuesday October 15 2019, @03:44AM

        by hendrikboom (1125) Subscriber Badge on Tuesday October 15 2019, @03:44AM (#907234) Homepage Journal

        Kind of hard to rip the intel CPU out of my laptop and replace it with a nonIntel architecture.

        I looked for performant alternatives before buying a Purism laptop. Failed to find them. Struggled with a Raspberry Pi for a while.

        Now, at least I don't have to contend with the Intel management engine.

        Waiting to see reviews of the Purism phone. Or the Pinephone.

        -- hendrik

      • (Score: 2) by DannyB on Tuesday October 15 2019, @03:07PM

        by DannyB (5839) Subscriber Badge on Tuesday October 15 2019, @03:07PM (#907396) Journal

        It is not enough to stop using the Win of WinTel, one must also stop using the Intel. Not all backdoors are software. So now I am more and more looking at ARM

        My best hope was ARM. But it still is proprietary and control of it focused in a central place. The government has no such agency that would want to control and subvert your hardware before the firmware then bootloader even begins.

        While it's still early, my hope lies in RISC-V. It's open source. RISC-V is to Intel as Linux is to Microsoft. As more and more chip makers fabricate chips based on the open design, it may simply be too much for no such agency to subvert all of them. If even any of them.

        Especially if all they do is execute instructions without any management engine. Remember how microprocessors were once able to do that? Amazing thing that was!

        If someone is to try to introduce a "management engine" it would -- at minimum -- have to be stealth. It must not require any support from the bootloader or OS. In fact, it must pretend to not exist. There must be no documented interfaces to it.

        --
        People today are educated enough to repeat what they are taught but not to question what they are taught.
  • (Score: 1) by zion-fueled on Monday October 14 2019, @01:51PM (7 children)

    by zion-fueled (8646) on Monday October 14 2019, @01:51PM (#906917)

    Despite all the security people crying, I've been turning off these mitigations for a while now. Some guides have a much shorter line that I use on linux mint that gets them all. Likelihood of somebody compromising my system is low and the performance hit is fairly big. Most of them are local vulnerabilities anyway unless you are running servers, in that case the performance hit probably isn't a big deal.

    • (Score: 4, Interesting) by The Mighty Buzzard on Monday October 14 2019, @03:16PM (6 children)

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Monday October 14 2019, @03:16PM (#906963) Homepage Journal

      Make sure you turn of javascript entirely and only whitelist sites you trust then. It's by definition allowing remote code to execute on your computer.

      --
      My rights don't end where your fear begins.
      • (Score: 1) by zion-fueled on Monday October 14 2019, @09:25PM (1 child)

        by zion-fueled (8646) on Monday October 14 2019, @09:25PM (#907123)

        Browser vulnerabilities don't need these CPU exploits. If they break out its game over.

      • (Score: 2) by driverless on Monday October 14 2019, @09:58PM (3 children)

        by driverless (4770) on Monday October 14 2019, @09:58PM (#907136)

        Firstly, most of the attacks aren't even remotely possible with JS unless it's been extended to do things like Flush+Reload since the last time I looked, and secondly browser vendors have already pretty much mitigated this stuff.

        • (Score: 2) by The Mighty Buzzard on Monday October 14 2019, @10:52PM (2 children)

          by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Monday October 14 2019, @10:52PM (#907152) Homepage Journal

          Do you trust browser vendors to cover every angle? I don't even trust myself to do so, which is why we keep martyb around. And things still slip by.

          --
          My rights don't end where your fear begins.
          • (Score: 2) by driverless on Monday October 14 2019, @11:03PM (1 child)

            by driverless (4770) on Monday October 14 2019, @11:03PM (#907155)

            No, but you've got to look at the probabilities: Most of the attacks aren't possible from JS in the first place, of the tiny fraction that are sort-off possible browser vendors have mitigated a lot of them, and then you'd have to be the target of someone hitting you with a highly advanced JS attack that can... do what? In an academic exercise they can steal your GPG key, but then they'd need to have some way of doing it via JS (unlikely, see above), get past browser mitigations (unikely, see above), persuade you to go to a web site hosting the malicious JS (requires a targeted attack), and then successfully pull it off. It's so far down the scale of threats that I'm really not losing any sleep over it, there are far more serious actual threats to worry about.

            • (Score: 2) by The Mighty Buzzard on Monday October 14 2019, @11:25PM

              by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Monday October 14 2019, @11:25PM (#907164) Homepage Journal

              No, no targeted attack necessary. Espionage is not the major worry today, bulk organized crime via compromised sites is. Dumping the exploit code onto tens of thousands of websites via a shittily coded wordpress plugin or the like and slurping up data from everyone that hits the site would be several orders of magnitude more likely.

              --
              My rights don't end where your fear begins.
  • (Score: 0) by Anonymous Coward on Monday October 14 2019, @03:00PM (2 children)

    by Anonymous Coward on Monday October 14 2019, @03:00PM (#906949)

    first they found flaws in software. the fix is ongoing.
    then they found flaws in hardware. the workarounds are ongoing.
    not far now and the flaws in then gens that grow the human brain will be found. the breeding continues ^_^

    • (Score: 0) by Anonymous Coward on Monday October 14 2019, @03:34PM (1 child)

      by Anonymous Coward on Monday October 14 2019, @03:34PM (#906970)

      flaws... are people!

      • (Score: 0) by Anonymous Coward on Monday October 14 2019, @06:20PM

        by Anonymous Coward on Monday October 14 2019, @06:20PM (#907072)

        Soon they'll get protections under the law! After all, those flaws were all created by WHITE MEN! WHITE MEN need to pay for those flaws! It's WHITE MAN fault that flaws are harmful!

(1)