Announcement

Collapse
No announcement yet.

Retbleed Impact, Overall CPU Security Mitigation Cost For Intel Xeon E3 v5 Skylake

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

  • Retbleed Impact, Overall CPU Security Mitigation Cost For Intel Xeon E3 v5 Skylake

    Phoronix: Retbleed Impact, Overall CPU Security Mitigation Cost For Intel Xeon E3 v5 Skylake

    Since the disclosure of Retbleed earlier this month as the newest CPU security vulnerability around speculative execution, I've posted some Intel/AMD benchmarks looking at the mitigation cost for the affected older generations of processors. Last week I also looked at the accumulated CPU mitigation cost on AMD Zen 1. Today is a similar comparison over on the Intel Xeon E3 v5 "Skylake" side with looking at the cost of just the Retbleed mitigations and then the overall CPU mitigation cost when toggling all of the various vulnerabilities with the "mitigations=off" flag.

    https://www.phoronix.com/review/xeon-skylake-retbleed

  • #2
    Typo:

    Originally posted by phoronix View Post
    The default Retbleed mitigatiosn on this Xeon E3 Skylake server can lead to longer build times now, even if keeping Hyper Threading enabled as all these tests were.

    Comment


    • #3
      It's a bloodbath, I'm saving up for Zen 4.

      Comment


      • #4
        Originally posted by Slartifartblast View Post
        It's a bloodbath, I'm saving up for Zen 4.
        Based on the past half decade or so I don't think it matters at this point. Just wait a bit and something new will come out that'll hit Zen 4 and Intel Gen whatever is equivalent to that and we'll be discussing Zen 5. Trying to fix x86 like that doesn't seem to be working.

        It makes me wonder if something like the Apple M route or pairing architectures is the way to go -- run the OS and "modern" software on the minimal/ARM/RISC CPU and either emulate or add x86 cores that can run unmitigated and isolated from everything else to run "legacy" x86 code.

        Comment


        • #5
          Originally posted by skeevy420 View Post

          Based on the past half decade or so I don't think it matters at this point. Just wait a bit and something new will come out that'll hit Zen 4 and Intel Gen whatever is equivalent to that and we'll be discussing Zen 5. Trying to fix x86 like that doesn't seem to be working.

          It makes me wonder if something like the Apple M route or pairing architectures is the way to go -- run the OS and "modern" software on the minimal/ARM/RISC CPU and either emulate or add x86 cores that can run unmitigated and isolated from everything else to run "legacy" x86 code.
          x86 internally has long not been a classic x86 CISC architecture and all ARM CPUs affected by Spectre are also affected by Retbleed. Spectre-class vulnerabilities affect all existing uArchs featuring speculative execution.

          Comment


          • #6
            So I'd rather to exchange retbleed for performance, because there is no hackers all day around me, but my gcc runs all day?

            Comment


            • #7
              mitigations=off

              Comment


              • #8
                Has there been a reliable exploit for any of the speculative execution vulnerabilities yet? By "reliable" I mean usable on an actually working computer, and not in a strictly controlled laboratory setting.

                Comment


                • #9
                  Weird question perhaps, but how does this scale to older hardware? These bugs affect all devices and I wonder his an Intel i7 4770 or i7 9770 handles this.

                  Perhaps something to test.

                  Comment


                  • #10
                    Originally posted by numacross View Post
                    Has there been a reliable exploit for any of the speculative execution vulnerabilities yet? By "reliable" I mean usable on an actually working computer, and not in a strictly controlled laboratory setting.
                    Atleast for spectre there was an online test (JS based). So if your running untrusted Code, always use mitigation.

                    Comment

                    Working...
                    X