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

  • #11
    Originally posted by ll1025 View Post
    Since when did the Linux enthusiast community become security-allergic luddites?
    Since when does ‚ÄčEspionage724 represent the whole Linux enthusiast community? Do you even logic or just like to troll?

    Comment


    • #12
      Edit: Disregard what I originally wrote here. I seem to have misread the first paragraph and got the impression that the 7950 wasn't affected when this is just confirming it on the lower end part.
      Last edited by L_A_G; 04 October 2022, 10:56 AM.
      "Why should I want to make anything up? Life's bad enough as it is without wanting to invent any more of it."

      Comment


      • #13
        Originally posted by L_A_G View Post
        Considering the fact that the higher end part with the exact same őľArch doesn't suffer from this puzzling ...
        Which higher part do you mean? Phoronix only showed 7950X and now 7600X.

        Comment


        • #14
          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.
          That does not make any sense, if this is what is happening then we would just see the same performance with mitigations=on as mitigations=off, not more performance with mitigations=on. The question is how the mitigations=off kernel code looks for the case with IBRS present vs how it looks with mitigations=on, could be that mitigations=off contains NOP:s as placeholders for IBRS and Ryzen 4 simply trigger some sync on NOP or something else like this.

          Comment


          • #15
            As far as I understand, Spectre V2 mitigation restricts Indirect branch speculations. Is it possible, that changes done by AMD (probably as part of hardware mitigation implementation) caused indirect branch speculation speed regression so much, that code runs much slower with indirect branch speculation enabled?

            Comment


            • #16
              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.
              Defensive much? I wasn't trying to pin a position on that; it is what it is (assuming it's true anyway). I don't advocate for disabling mitigations and don't exactly mind where the mitigations are either way.

              If I was looking for top CPU performance in an environment I control (usually I run Windows for VR set-ups like this), I disable mitigations because they do actively slow things down, and the CPUs I usually use aren't high-end. I trust hardware mitigations wouldn't remotely be an issue on newer CPUs.

              Comment


              • #17
                keep in mind that CPU by law must have backdoors and vulnerabilities. Same with encryption or in case of court cases/investigations you must give out your password.

                Comment


                • #18
                  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.
                  Show me a fucking desktop PC ever exploited by this crap first.

                  Comment


                  • #19
                    Originally posted by cj.wijtmans View Post
                    keep in mind that CPU by law must have backdoors and vulnerabilities. Same with encryption or in case of court cases/investigations you must give out your password.
                    That's only true for repressive governments. In a real democracy no one can force you to give out passwords or build in backdoors.

                    Comment


                    • #20
                      Unfortunately the UK counts as a repressive government.

                      As for performance vs. security, I did stick with TLS 1.2 because it was the only way to retain compression of PostgreSQL replication streams. Had to recompile OpenSSL packages, but it's worth it for a 60% saving in bandwidth used. Transfer isn't free on all providers, and if an attacker has the skill to pull off a CRIME-variant attack on our replication, they probably have access to other methods of attack, including legal ones.

                      In some cases, disabling mitigations may be appropriate too. In others, like open multiuser systems or VM hosting, it is probably not. It's good to see that we now have some CPUs where that tradeoff doesn't need to be considered.

                      Comment

                      Working...
                      X