Announcement

Collapse
No announcement yet.

With AMD Zen 4, It's Surprisingly Not Worthwhile Disabling CPU Security Mitigations

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

  • #51
    Beta Intel: "We need to add hardware to memory sticks to flag regions of RAM as 'disable all speculation' to prevent errors. No we're not going to also add and require ECC support in all chipsets & RAM used with our CPUs, to end Rowhammer type attacks forever at the same time."

    Sigma AMD: "We fixed our shit, and so hard it's better with fixes than without."

    ...am I doing this meme right? It feels ridiculous enough, and leaves out how AMD is not requiring motherboard manufacturers to accurately report ECC support in consumer boards.

    Comment


    • #52
      Originally posted by atomsymbol

      Unable to decrypt meaning.
      If the slow-down is due to branch misprediction, then it's Your Own Damn Fault™ if you use mitigations=off​ because it's become equivalent to feeding a less effective mtune setting to GCC.

      If the compiler's branch predictor is already a dozen steps ahead into the assumption that a mitigation is going to run, and then it doesn't, it has to throw out all that work and start over.

      Comment


      • #53
        Originally posted by ssokolow View Post

        If the slow-down is due to branch misprediction, then it's Your Own Damn Fault™ if you use mitigations=off​ because it's become equivalent to feeding a less effective mtune setting to GCC.

        If the compiler's branch predictor is already a dozen steps ahead into the assumption that a mitigation is going to run, and then it doesn't, it has to throw out all that work and start over.
        Wouldn't fixing the bug and then adding the CPU to the whitelist for the security flaw mitigations be a better course of action?

        Comment


        • #54
          Originally posted by andrebrait View Post

          Wouldn't fixing the bug and then adding the CPU to the whitelist for the security flaw mitigations be a better course of action?
          I don't claim to speak for AMD. I'm just pointing out what could cause mitigations=off to perform worse without it being a bug in the kernel.

          Comment


          • #55
            Originally posted by atomsymbol
            Basically, the results mean that there is a mitigations=off performance bug in the Linux kernel.
            Rather presumptuous statement. They claim to have fixed the hardware but we don't know how.
            It would not be the first time that cleverly tuned kernel software proved faster than the hardware alternative.
            The processor could be detecting unsafe code and fixing it, that could be slow, while running safe code is faster.

            Comment


            • #56
              I think they simply tuned the branch prediction to expect software with mitigations.

              Comment


              • #57
                Originally posted by atomsymbol

                Seems like a set of random words without meaning.

                Please explain:
                • Where exactly is the branch misprediction supposed to be happening?
                • What exactly is supposedly causing the CPU to mispredict the branches?
                • Do you mean Zen4's new feature "Automatic IBRS" or do you mean something else?
                Others have no trouble finding meaning without me going into that fine detail and I'm neither an AMD engineer nor defending a PhD thesis nor getting paid to answer your questions, so these are the answers you get:
                • Download AMD uProf and investigate it yourself.
                • Maybe AMD re-tuned the branch predictor to expect a software mitigation after a certain sequence of instructions.
                • I just mean that maybe AMD re-tuned the branch predictor.

                Comment


                • #58
                  Originally posted by atomsymbol

                  My reasoning is the following:
                  1. The Phoronix article doesn't specify whether the increase is in user-space time or kernel-space time or both
                  2. However, based on the chart in the article, it is more probable that the increase is in user-space time and less probable that it is in kernel-space
                  Ha! Thanks for confirming the article has a chart!

                  Michael, I think there's a bug in the article. I see the chart in Chrome, but not in Firefox on 2 different PCs, whether or not I'm signed into Phoronix Premium. The page is truncated right before that.

                  Comment


                  • #59
                    Originally posted by geearf View Post

                    Isn't that an optimization in hardware and not a fix then?
                    Does that mean that a proper fix is impossible without disabling speculation?

                    Thank you!
                    Designers will always look for more hardware optimizations. It's the ONE AND ONLY reason computers have continued to get faster, even as software becomes more bloated.

                    Speculation is one of the most powerful hardware optimizations ever invented, allowing parallel processing to improve serial execution speed. It's perfectly fine to speculate on *most* branches, but you need to A) mark the security-critical ones for exclusion and B) flush them on context switch. The hardware NEEDS to be told when those two things are happening.

                    Once it *is* being told, then it's perfectly possible to design optimizations that take it into account. For example, being told you are moving from one context to another on the downside forces you to flush old predictions that would have leaked data (resetting predictions to random chance), but on the upside allows you to flush old predictions that would tell you the wrong thing in the new situation.

                    Comment


                    • #60
                      Originally posted by coder View Post
                      Ha! Thanks for confirming the article has a chart!

                      Michael, I think there's a bug in the article. I see the chart in Chrome, but not in Firefox on 2 different PCs, whether or not I'm signed into Phoronix Premium. The page is truncated right before that.
                      I am using Firefox and I see the chart. Do you have content or scripts from openbenchmarking.org blocked? AFACT, the chart is an SVG, hosted on openbenchmarking.org, dynamically inserted into the page by a script, also hosted on openbenchmarking.org.

                      Comment

                      Working...
                      X