Announcement

Collapse
No announcement yet.

Disabling Spectre V2 Mitigations Is What Can Impair AMD Ryzen 7000 Series Performance

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

  • Disabling Spectre V2 Mitigations Is What Can Impair AMD Ryzen 7000 Series Performance

    Phoronix: Disabling Spectre V2 Mitigations Is What Can Impair AMD Ryzen 7000 Series Performance

    Last week I shared some initial numbers how surprisingly when disabling Zen 4 CPU security mitigations can actually *hurt* the Ryzen 7000 series CPU performance. While conventional wisdom and with past Intel/AMD processors yield better performance when disabling the CPU security mitigations, with the Ryzen 9 7950X it was found to be basically the opposite. I have since conducted more tests and using an AMD Ryzen 5 7600X to confirm the earlier results and dig deeper into the data.

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    My theory is that fixing the Spectre V2 vulnerability on a hardware level would lead to fundamental architecture changes that AMD is not willing to make, because it may add so much more complexity to the architecture or it may just be too unconvenient. They probably realized that optimizing the code paths that the Linux kernel utilizes on the default mitigations mode is faster, simpler and it may involve less deeper changes, while still being secure.

    As far as I know, pretty much every CPU architecture that implements speculative execution is vulnerable to some version of Spectre, so note that this is not a fundamental flaw of AMD64.
    Last edited by EvilHowl; 05 October 2022, 03:24 AM.

    Comment


    • #3
      So now instead of being able to disable mitigations and get the processor's full-performance, the mitigations are built-in, presumably causing the same impact, and now can't be disabled?

      Comment


      • #4
        There's some trickery going on, e.g. the CPU could completely discard the instructions which are meant to protect against Spectre but there are other protections in place so the vulnerability is taken care of. Amazing I'd say except this could open the door to new vulnerabilities.

        Comment


        • #5
          Isn't it possible that there's a kernel bug or that it's less optimized? It isn't impossible but it sounds weird that removing mitigations hurts performance. And we've seen in the past that somewhat new processors had lots of weird scheduling and clocking regressions. Is the same effect observed in Windows or *BSD?

          Comment


          • #6
            BTW mitigations=off just disable some (not all) mitigations that should slow down the system. In this case it should not disable the mitigations which won't slow down or make the system faster.

            Comment


            • #7
              Interesting results. I suppose it's a good thing that mitigated=faster. Makes me wonder if they figured out an algorithm that makes mitigated code faster than unmitigated -- like if they know a range of stuff isn't going to be valid due to how mitigations work, just not operate or branch predict or WTF ever on that range versus the old way of doing it and tossing it aside or flushing the cache or something. Y'all get what I mean.

              phoronix

              Page 1:

              based on the CPU MSrs and applied

              return stack buffer (RSB) filling
              You didn't use the shift key for those.

              So to curious and dig deeper,
              Perhaps use, "Out of curiosity and to dig deeper," or "For those who are curious and to dig deeper,"

              I can't tell which one you meant for that to mean.

              Page 2:

              "spectre_v2=off" to disabling the
              "to disable"

              Page 3:

              Including code compilation workloads were negatively
              Should this be, "In addition to code compilation, workloads were negatively"?

              At a minimum add a comma between compilation and workloads.

              Comment


              • #8
                Originally posted by Espionage724 View Post
                So now instead of being able to disable mitigations and get the processor's full-performance, the mitigations are built-in, presumably causing the same impact, and now can't be disabled?
                Since when did the Linux enthusiast community become security-allergic luddites?

                Do you also setenforce 0 and run as root? Maybe you stick to 1024 bit RSA because it's faster? And what's with that lengthy key exchange in SSH, take us back to telnet!

                It's 2022, and sentiments like yours are responsible for the massive cybercrime industry's success. Whether on Linux or Windows, this kind of "it'll never get me" attitude is exactly how they get you.

                Comment


                • #9
                  Originally posted by ll1025 View Post

                  Since when did the Linux enthusiast community become security-allergic luddites?

                  Do you also setenforce 0 and run as root? Maybe you stick to 1024 bit RSA because it's faster? And what's with that lengthy key exchange in SSH, take us back to telnet!

                  It's 2022, and sentiments like yours are responsible for the massive cybercrime industry's success. Whether on Linux or Windows, this kind of "it'll never get me" attitude is exactly how they get you.
                  Dammit. Schrodinger's Comment. While I agree with the sentiment, not every PC is internet facing or needs that kind of security. Something like a massive video encoding or graphics rendering farm behind layers of firewalls and security doesn't need or want mitigations enabled, or, rather, didn't traditionally need or want them enabled.

                  Comment


                  • #10
                    Originally posted by birdie View Post
                    There's some trickery going on, e.g. the CPU could completely discard the instructions which are meant to protect against Spectre but there are other protections in place so the vulnerability is taken care of. Amazing I'd say except this could open the door to new vulnerabilities.
                    Yes, I believe this is a mistake that is going to backfire and hurt Zen4 later when new CVE is discovered because of this.
                    Also, this "optimization" seems very fragile.

                    What if the spectre v2 migration in linux changed in the future?
                    Even some slight changes can shift the performance dramatically.

                    I do wonder whether this behavior also exhibits on windows.
                    If so, then the tuning might be even more sensible to changes in the kernel.

                    Comment

                    Working...
                    X