Announcement

Collapse
No announcement yet.

A Look At The CPU Security Mitigation Costs Three Years After Spectre/Meltdown

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

  • #11
    Originally posted by MadCatX View Post
    What's up with 5950X? It seems to be affected more than the older AMD chips. The AMD chips overall suffer a bit more than I expected.

    Zen 3 is a lot more "snappy" compared to previous iterations. So it stands to lose more of that snappiness from mitigations getting in the way of optimal operation.

    Much like a sports can will lose more of its top speed driving through a corn field than a mainstream car.

    Although them encryption results look more like a bug than mitigation penalty.

    Comment


    • #12
      Originally posted by ddriver View Post

      Although them encryption results look more like a bug than mitigation penalty.
      See the aforelinked and past articles around AES-NI XTS in the presence of Retpolines.
      Michael Larabel
      http://www.michaellarabel.com/

      Comment


      • #13
        I wonder why is the 5950X being hit hard here......

        More cores or more vulnerabilities? Or slower mitigations?

        Comment


        • #14
          I thought new hardware had hardware fixes for this. Why are mitigations still enabled?

          Comment


          • #15
            Originally posted by bobbie424242 View Post
            If you trust your distro and software, mitigations=off FTW !
            No. This is not wise. Don't recommend this to others.

            Comment


            • #16
              Originally posted by tildearrow View Post
              I wonder why is the 5950X being hit hard here......

              More cores or more vulnerabilities? Or slower mitigations?
              I have the same question, something looks very wrong with the results. I don't know if this is kernel, kernel-scheduling, compiler or even application related.

              There are many changes between Zen3 and Zen2 ... much more than Zen2 and Zen1. The 4 to 8 CCX alone is massive in how the chip's internal latency behaves. I have not been following patches at all, so I'm sorry if I've missed something directly related to this change in hardware. In any case rather big change in scheduling would have been required. There are many other factors that would require optimization for many individual instructions, yet I don't think that this is a problem maybe just a missed optimization. Windows applications probably don't have these optimizations and they appear to get much better results from zen3 CPUs. As always info from wikipedia and wikichip is very useful for reviewing hardware changes, however this time I found Anandtech's research was outstanding.

              Typically when designing a CPU core, the easiest thing to do is to take the previous design and upgrade certain parts of it – or what engineers call tackling ‘the low hanging fruit’ which enables the most speed-up for the least effort. Because CPU core designs are built to a deadline, there are always ideas that never make it into the final design, but those become the easiest targets for the next generation. This is what we saw with Zen 1/Zen+ moving on to Zen 2. So naturally, the easiest thing for AMD to do would be the same again, but with Zen 3.

              However, AMD did not do this. In our interviews with AMD’s senior staff, we have known that AMD has two independent CPU core design teams that aim to leapfrog each other as they build newer, high performance cores. Zen 1 and Zen 2 were products from the first core design team, and now Zen 3 is the product from the second design team. Naturally we then expect Zen 4 to be the next generation of Zen 3, with ‘the low hanging fruit’ taken care of
              https://www.anandtech.com/print/1621...d-5700x-tested

              They found out some things that AMD did not publish (not part of the quote below). It's a good long technical read.

              Comment


              • #17
                Originally posted by Mangix View Post
                I thought new hardware had hardware fixes for this. Why are mitigations still enabled?
                Not for Spectre. No modern x86 CPU has spectre-proof hardware. Here is my 11th gen Tiger Lake machine running Fedora 33. Looks like intel fixed the other stuff, but not Spectre:

                Vulnerability Itlb multihit: Not affected
                Vulnerability L1tf: Not affected
                Vulnerability Mds: Not affected
                Vulnerability Meltdown: Not affected
                Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
                Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
                Vulnerability Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
                Vulnerability Srbds: Not affected
                Vulnerability Tsx async abort: Not affected


                Comment


                • #18
                  Typo: one of the "CPUs" is written as "CPus"

                  Comment


                  • #19
                    Originally posted by juxuanu View Post
                    As far as I know, there have been no reports of any personal computer being exploited by a malicious software taking advantage of these vulnerabilities, ever. Does anyone know of any?
                    I have all my computers with mitigations=off since I only install from repos or trusted sources.
                    Same with my PC, and because it's Linux I didn't change my behavior since, apparently you have to wish for it to get a virus.

                    Comment


                    • #20
                      Originally posted by torsionbar28 View Post
                      Not for Spectre. No modern x86 CPU has spectre-proof hardware. Here is my 11th gen Tiger Lake machine running Fedora 33. Looks like intel fixed the other stuff, but not Spectre:

                      Vulnerability Itlb multihit: Not affected
                      Vulnerability L1tf: Not affected
                      Vulnerability Mds: Not affected
                      Vulnerability Meltdown: Not affected
                      Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl and seccomp
                      Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization
                      Vulnerability Spectre v2: Mitigation; Enhanced IBRS, IBPB conditional, RSB filling
                      Vulnerability Srbds: Not affected
                      Vulnerability Tsx async abort: Not affected

                      Why is that?

                      Comment

                      Working...
                      X