Announcement

Collapse
No announcement yet.

Benchmarking Linux With The Retpoline Patches For Spectre

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

  • #11
    Some of the AMD koolaid drinkers need to learn how to read: "Note that these kernels do have the already-merged KPTI support present and enabled for Intel CPUs for Meltdown protection. "

    OK. What does that say? It says that KPTI was turned on for Intel parts. Given that the official mainline Linux kernel disables KPTI for AMD unless you go out of your way to turn it on, it's pretty clear that KPTI was turned off unless Larabel wants to share the boot parameter that he used to manually enable it for the AMD hardware.

    Comment


    • #12
      Originally posted by chuckula View Post
      Some of the AMD koolaid drinkers need to learn how to read: "Note that these kernels do have the already-merged KPTI support present and enabled for Intel CPUs for Meltdown protection. "

      OK. What does that say? It says that KPTI was turned on for Intel parts. Given that the official mainline Linux kernel disables KPTI for AMD unless you go out of your way to turn it on, it's pretty clear that KPTI was turned off unless Larabel wants to share the boot parameter that he used to manually enable it for the AMD hardware.
      Yes, this. KPTI is disabled by default for AMD. Michael didn't go out of his way to enable them on AMD.

      My Yikes comment was more about what the pre-KPTI/Retpoline vs after benchmarks will look like, especially on Intel CPUs.

      Comment


      • #13
        Originally posted by chuckula View Post
        Some of the AMD koolaid drinkers need to learn how to read....
        Thx for the, ..........ahem........, "clarification"? And, of course, the name-calling.

        Comment


        • #14
          For people not reading the article... KTPI wasn't enabled for the AMD CPUs.
          Michael Larabel
          https://www.michaellarabel.com/

          Comment


          • #15
            thx, man.

            Comment


            • #16
              Interesting how the server chips seem largely unaffected. Considering these security risks were mainly due to trying to maximize pipeline usage, I wonder if the lower clocks of server CPUs in turn decreases the opportunities to fill it up. I could totally be wrong though, I'm not too fluent in how all this low-level stuff works.

              Originally posted by chuckula View Post
              Some of the AMD koolaid drinkers need to learn how to read: "Note that these kernels do have the already-merged KPTI support present and enabled for Intel CPUs for Meltdown protection. "
              Koolaid doesn't inhibit your thought process. Perhaps you should lay off the alcohol?
              OK. What does that say? It says that KPTI was turned on for Intel parts. Given that the official mainline Linux kernel disables KPTI for AMD unless you go out of your way to turn it on, it's pretty clear that KPTI was turned off unless Larabel wants to share the boot parameter that he used to manually enable it for the AMD hardware.
              Even if what you said were true, had it ever occurred to you that it's just a precaution? AMD hardware is still vulnerable, but not to the degree that Intel is. From what I heard, Intel's vulnerability can be exploited remotely, whereas AMD (and ARM) need direct hardware access. There's still a lot we don't know about how to solve this problem, so for the time being it makes perfect sense to just patch the kernel across the board.

              Comment


              • #17
                Reading this thread is a little confusing...

                Anyway, I'd like to see a before and after for both patches just to see what the full impact has been.

                Comment


                • #18
                  Originally posted by schmidtbag View Post
                  Interesting how the server chips seem largely unaffected. Considering these security risks were mainly due to trying to maximize pipeline usage, I wonder if the lower clocks of server CPUs in turn decreases the opportunities to fill it up. I could totally be wrong though, I'm not too fluent in how all this low-level stuff works.


                  Koolaid doesn't inhibit your thought process. Perhaps you should lay off the alcohol?

                  Even if what you said were true, had it ever occurred to you that it's just a precaution? AMD hardware is still vulnerable, but not to the degree that Intel is. From what I heard, Intel's vulnerability can be exploited remotely, whereas AMD (and ARM) need direct hardware access. There's still a lot we don't know about how to solve this problem, so for the time being it makes perfect sense to just patch the kernel across the board.
                  That's a great fact-free AMD press-release comment there with some delusional nonsense about how only Intel hardware can be exploited "remotely" by these bugs that totally ignores the research that was done about using a web browser to implement these attacks on ... you guessed it... Ryzen parts too: https://spectreattack.com/spectre.pdf

                  What's even funnier is that you wasted the time to type up that crap after Larabel already confirmed that KPTI was turned off to present AMD in the best possible light.

                  Comment


                  • #19
                    What the f4ck, wasn't supposed to be "negligible"? -.-
                    ## VGA ##
                    AMD: X1950XTX, HD3870, HD5870
                    Intel: GMA45, HD3000 (Core i5 2500K)

                    Comment


                    • #20
                      Originally posted by darkbasic View Post
                      What the f4ck, wasn't supposed to be "negligible"? -.-
                      Dependent on the workload (i.e. redis is gonna suffer). Let's make sure we don't sh*t on kernel developers and others who have been working tirelessly to secure our machines. The performance hit is NOT on them, but the hardware manufacturers (specifically Intel since AMD figured out how to preemptively avoid Meltdown). It's an unfortunate situation.

                      Comment

                      Working...
                      X