Announcement

Collapse
No announcement yet.

The Performance Cost Of Spectre / Meltdown / Foreshadow Mitigations On Linux 4.19

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by Michael View Post

    Yep, http://openbenchmarking.org/result/1...WN82&obr_imw=y As always things are transparent with Phoronix Test Suite and OpenBenchmarking.org.
    Awesome, thanks for the link! I'm new to the site.

    Comment


    • #12
      When first microcode updates were made for Ironlake performance suffered the most on those chips (50% or so) so I blocked all microcode updates on that machine and kept old driver. With recent kernels however now there is also "firmware bug" message which tells me to update. Should I worry about it?

      [ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
      [ 0.585955] microcode: sig=0x306c3, pf=0x2, revision=0x12
      [ 0.586078] microcode: Microcode Update Driver: v2.2.

      Comment


      • #13
        Been looking forward to these tests, I suspected that the mitigation could cause a lot (which in my mind was 5-10%) of performance loss.. Turns out it's even worse than that :O. As I currently use my linux desktop mostly for gaming, movies, web browsing and similar tasks it feels like its worth turning the mitigations off for some increased performance. I have yet to see an exploit that uses these, and if there is one, I can't think of any private data I have that could be worth stealing.

        Comment


        • #14
          Originally posted by ryszardzonk View Post
          When first microcode updates were made for Ironlake performance suffered the most on those chips (50% or so) so I blocked all microcode updates on that machine and kept old driver. With recent kernels however now there is also "firmware bug" message which tells me to update. Should I worry about it?

          [ 0.000000] [Firmware Bug]: TSC_DEADLINE disabled due to Errata; please update microcode to version: 0x22 (or later)
          [ 0.585955] microcode: sig=0x306c3, pf=0x2, revision=0x12
          [ 0.586078] microcode: Microcode Update Driver: v2.2.
          Sounds like you have Haswell. The error it is referring to is TSX being disabled on Haswell after launch. This is separate from the Spectre/Meltdown/L1TF vulernabilities and mitigations.

          Personally, I'd update to microcode 22 like the error is saying. Microcode 23 was the first to include Spectre/Meltdown mitigations. And 25 is the latest version with L1TF. So if security is of upmost importance to you, use the latest kernel and microcode 25. It sounds like you're on microcode 18 right now but I'm not entirely sure.

          On my Haswell machine (the signature is same as yours), I have microcode 22 which you can check by:

          $ dmesg | grep 'microcode'
          [ 0.000000] microcode: microcode updated early to revision 0x22, date = 2017-01-27
          [ 0.595515] microcode: sig=0x306c3, pf=0x2, revision=0x22
          [ 0.595548] microcode: Microcode Update Driver: v2.2.

          Pretty straightforward if you want to get it going on your machine without installing any package. But only do the following if you feel comfortable. The package "intel-microcode" (sudo apt install intel-microcode) will do this all for you, but will install the latest microcode with the Spectre/Meltdown mitigiations (microcode 25).

          If you want microcode 22 and are willing to install it yourself. Head over to intel's site here to download. The link I provided will download microcode 22 (20171117). If you decide you want microcode 25, select 20180807 from the left side. They have instructions on the site, but here are mine if it helps:

          $ tar xvf microcode-20171117.tgz microcode-20171117
          $ cd microcode-20171117

          First back up current microcode:

          $ sudo cp -r /lib/firmware/intel-ucode ~/Downloads/intel-ucode-backup

          Copy over new one:

          $ sudo mv intel-ucode /lib/firmware/intel-ucode

          Then, as root, reload the microcode:

          $ echo 1 > /sys/devices/system/cpu/microcode/reload

          Check results by: $ dmesg | grep microcode

          To make it permanent, update your initramfs:

          $ sudo update-initramfs -u (or "sudo update-initramfs -u -k all" to do all kernels) and then reboot. And double check by $ dmesg | grep microcode to confirm.

          Comment


          • #15
            Originally posted by captainohair View Post

            Awesome, thanks for the link! I'm new to the site.
            Welcome and enjoy. You should find that our testing is the most transparent and open and reproducible out of pretty much any website I am aware of.
            Michael Larabel
            http://www.michaellarabel.com/

            Comment


            • #16
              Greg Kroah-Hartman spoke today on Spectre/Meltdown:

              "Intel siloed SUSE, they siloed Red Hat, they siloed Canonical. They never told Oracle, and they wouldn't let us talk to each other."

              For an initial set of vulnerabilities, Kroah-Hartman said the different Linux vendors that typically work together. However, in this case they ended up working on their own, and each came up with different solutions.

              "Jann Horn discovered the first issues in July of 2017, but it wasn't until Oct. 25 of last year that some of us in the kernel community heard rumors of the flaw," he said. "That's a long time, and we only heard rumors because another very large operating system vendor told Intel to get off their tails and tell us about it."

              "It really wasn't working, and a number of us kernel developers yelled at [Intel] and pleaded, and we finally got them to allow us to talk to each other the last week of December [2017]," he said. "All of our Christmas vacations were ruined."
              Fuck Intel.

              To Intel's credit, Kroah-Hartman said that after Linux kernel developers complained loudly to the company in December 2017 and into January 2018, it fixed its disclosure process for future Meltdown- and Spectre-related vulnerabilities.

              With the most recent variant of Meltdown and Spectre, which has been dubbed Foreshadow and was publicly disclosed on Aug. 14, Kroah-Hartman said Linux kernel developers were properly notified ahead of time, so that fixes could be made in a collaborative way by the Linux community.

              "Intel has gotten better at this," he said.
              I don't care. See above.

              "Windows and Linux kernel developers now have this wonderful back channel. We're talking to each other and we're fixing bugs for each other," Kroah-Hartman said. "We are working well together. We have always wanted that."
              Some good news finally. Thank you again to everyone involved. We owe you guys big time.

              Comment


              • #17
                Originally posted by perpetually high View Post
                Sounds like you have Haswell.
                ...
                $ echo 1 > /sys/devices/system/cpu/microcode/reload
                You are right about haswell. I don't know why I always fought it was Ironlake

                I do have microcode-20171117 installed. However I did not use initramfs to load microcode, but the old fasion way with microcode_ctl. I guess they switched something in kernel as this method simply stopped working and I did not notice it does not load microcode updates anymore. Gentoo I use warns that it would not work with recent firmwares, but they failed to mention it would not work for old ones either.

                Method for loading microcode worked.
                [735362.206041] microcode: updated to revision 0x22, date = 2017-01-27

                Hopefully grub updates I did will work and load microcode as well...

                Comment


                • #18
                  On Intel side it's a fucking disaster. We are basically thrown a generation back.
                  Last edited by birdie; 31 August 2018, 05:09 AM.

                  Comment


                  • #19
                    Similar tests with desktop CPUs and more desktop focused workloads will be carried out on Linux 4.19 if there us sufficient interest.
                    I'd be interested to see that, if you have the time to make it. Would be also interesting to see how a laptop CPU is affected, if you can throw in the XPS 13 with the 8550U too.

                    Comment


                    • #20
                      AMD really are doing amazingly well with their CPUs right now. Faster for parallel work loads (per dollar). Less affected by the speculative execution issues. Higher core counts for their CPUs in most their market segments.

                      The main thing Intel has still got the lead on is performance per thread. If you want maximum FPS in your games, Intel is currently your best bet. For almost everything else: AMD seems to be a better option.

                      Comment

                      Working...
                      X