Announcement

Collapse
No announcement yet.

The Brutal Performance Impact From Mitigating The LVI Vulnerability

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

  • #41
    Originally posted by bug77 View Post
    Basically, this puts to shame all the other vulnerabilities combined.
    Try to tell that you your body, while facing COVID-19,...

    Comment


    • #42
      Originally posted by dweigert View Post
      Ugh... I can't afford Epyc based servers at the moment. I will be building out a Threadripper box though. I'm done with Intel for a while.
      I would not be surprised if the researchers were only focusing on Intel and might set their sights on AMD/POWER/ARM next ...
      Last edited by Raka555; 13 March 2020, 06:47 AM.

      Comment


      • #43
        Originally posted by ms178 View Post
        With these performance numbers, everyone who is dependant on the security and does use workloads like shown here, they shouldn't re-compiler their software with these mitigations but kick these Intel systems out the door and get something from the competition instead.
        Are you 100% sure the competition in x86 segment doesn't have security issues?
        The fact that you are not aware of security issues with the competition =/= the competition doesn't have them.

        If we look at AMD situation is like this:
        1) Brisbane saw no microcode update (doubt this was the bug free cpu)
        2) K10 familly stopped receiving microcode updates before the last member (talking here about AM3 cpus) was released on the market (doubt they fixed all the bugs before the last cpu was released on the market)
        3) Bulldozer, the architecture that didn't supposed to even be released (that's how bad it was when looking at performance and TDP) (doubt many wasted their time with Bulldozer) (when I say Bulldozer I include the minor improvements to this particular architecture; for me improvements =/= new architecture (this applies to Intel because later I will say about 10 years old Intel architecture, because everything after are improvements and nothing else))

        So before Ryzen situation was not really nice in AMD case.
        Ryzen architecture is the only one that actually deserve the time and effort to find bugs. But Ryzen is 3 years old architecture. Sure AMD recovered a bit in term of market share, but it's stil considerable below Intel.

        Now Intel basicaly has an 10 years old architecture (improvements are not new architecture in my eyes). Situation was like this because there was no real competition (looking at Faildozer...).
        When you have the market share on your side, when for years you dominated the servers area (where they are really interested in security) ofc people focused on finding bugs.
        Add the money from the bug bounty program and you kinda see why people had the time and the motivation to find bugs in Intel case.

        There is another problem regarding AMD. How they react when you report them a bug.
        I have a personal example from Windows gpu driver area. I reported them a bug some years ago. The answer was : "it's a game engine bug". Before writing such abberation maybe just maybe you should launch that particular game (especially when it was and still is a popular game, not a game that like nobody knows about) with your previous gpu generation, install the windows drivers and see that you are unable to replicate the bug I reported, but you can replicate it with your new gpu generation (either a bug in the hardware or a bug in your drivers). For me this told me a bit about how much they actually check when you report them a bug. Taking into consideration that the bug was affecting all dx9 games it was actually needed to fix it. It was in their own interest to fix it yet they basicaly didn't cared. As result I decided that this situation fits in one of the cases when I can make exceptions from my moral principles and I basicaly public humiliated one of their reps with strong evidences (I made him look like an idiot for everything he was writing about this problem. yes I did it the hard way but it was also the only way to get the bug fix in their drivers). Yes I got that bug fixed but since then I'm basicaly blacklisted by AMD. No matter what bug i report to them it's totaly ignore. no matter how strong the evidences are. Don't get me wrong, but I stopped reporting them bugs, what's the point when I basicaly waste my time and energy and they ignore me (because they don't care from my point of view).
        Result is that I do whatever I want if I find a bug related to AMD products (that includes even selling it on the black market). AMD made it like this. not me. I just concluded it's impossible for me to communicate in a polite way with them because: a) they deny there is a bug totaly ignoring the evidences b) they ignore me. How can I communicate with someone that ignores me?!? Looks bad I know. But when the other side refuses to fix something that needs to be fixed the only way to do it is the hard way (they usually understand when they lose money, but I've meet some case that didn't understood when they lost money; last part in this () is not related to AMD).
        Situation hasn't improved at all in the last 10 years. What happens with AMD Windows drivers tells a lot about how they handle the bugs. Sure you can say it's Windows, it's another division.
        How can I believe that in other departments situation is better when in one of them there is basically total chaos (for the windows gpu driver I'm 99,99% they don't push patches to fix something, they just build it completly and teams don't talk with each other and don't really share to what they work, else I can't explain how they fix a bug in a driver, next driver has the bug and then the bug stay there for years).

        Yes I know I might look like an Intel fan, but it's not the case.
        I want things to be better and I believe that with only 2 real players in x86 cpu market things are plain bad. (Current situation with ARM in smartphone is not good at all. When you need the manufacturer to build the entire firmware so you can update your Android device things are not good at all. What if that manufacturer decided to never build a new firmware except the initial one for that smartphone (to software obsolate the devices to force you buy another one)?)
        I just dislike ignorance.

        Look let's assume I find bugs in the hardware of 2 distinct manufacturers. Let's call them "X" and "Z".
        "X" totaly ignores me and does nothing to fix the bug I reported.
        "Z" offers me money to not ever public the bug I found in their hardware.
        I find both behaviours as bad. But "Z" when it made the decision to offer me money to silence me actually admited that I'm right. Sure "Z" cared more about their image than fixing the bugs, but "X" didn't cared about their image or about fixing the bug.
        So "Z" behaviour is a bit better than "X" behaviour but both are in the bad category.

        When you cut corners to gain performance it's a matter of time until someone will find a way to exploit what you've done.
        Last edited by thedukesd; 13 March 2020, 07:31 AM.

        Comment


        • #44
          the best solution would be to arm the browsers against these vulnerabilities, and leave all the other software alone which does not necessarily need to be online ...
          you have to go back a bit to the old ... and clearly separate between online and offline.

          in my opinion it is better to set a firewall with all armored doors and only those of the browser open.
          so if there is some clever malicious software that plays tricks it cannot come out.
          for clients this is the ideal solution.
          Last edited by nokipaike; 13 March 2020, 08:03 AM.

          Comment


          • #45
            Originally posted by thedukesd View Post
            Are you 100% sure the competition in x86 segment doesn't have security issues?
            The fact that you are not aware of security issues with the competition =/= the competition doesn't have them.
            I consciously used the broader term "competition" here, as I didn't want to single out a specific vendor (as ARM and POWER also offer alternatives). But I understand, if people are reliant on x86 they only have the choice today to go with AMD instead. Maybe some people in the industry did wake up that more competition on the ISA-level would be healthier for the whole computing business?

            By the way, from the reports I have seen during the last two years, researchers were actively scrutinizing not just Intel but also other vendors for hardware security flaws. And there were some issues with other vendors as well, but a) they were far less severe in comparison and b) due to different architectural decisions they enjoy an inherent advantage for some attack vectors. But to answer your question: I cannot rule out that the other vendors are also plagued with security flaws. That doesn't mean that Intel's flaws are of a lesser concern, as the dominant player the impact is much more severe with them.

            I can understand your frustrations with how things went with you and AMD, but that is well beyond the scope of this topic.

            Comment


            • #46
              Originally posted by nokipaike View Post
              just out of curiosity, the situation is theoretically dramatic in the same way even on windows right?
              It's probably much worse. I can only imagine updating this mess on Windows..

              Comment


              • #47
                Damn... I expected the impact to not be anything to sneeze at, but this is just an order of magnitude worse than I thought.

                They will probably introduce updates to these mitigations over the coming weeks and months that lessen the performance impact like they have with the Spectre and Meltdown fixes, but even after that it won't be anything to sneeze at then either.

                Still, I've previously said about the continuous string of speculative execution attacks that it's a case of "When it rains it pours" but this is more like a class 5 hurricane.

                Comment


                • #48
                  Does just disabling SMT/HT impact performances less than having it enabled + using mitigations?

                  Comment


                  • #49
                    Originally posted by TemplarGR View Post
                    Just disable hyperthreading (SMT) people. It is a garbage technology anyway. For most use cases it provides tiny benefits, especially for most desktop users, any benefits aren't worth the security holes. Better than using costly mitigations....
                    This is simply not true. Only Intel's design is vulnerable and AMD's is fine (so far). For example a simple 7-zip benchmark scales almost 2x from 8 physical cores on a 3700X:


                    It all depends on the type of workload, of course. More floating point makes it scale less, more memory accesses has the same effect, and so on.


                    Originally posted by TemplarGR View Post
                    Now Zen is just a me-too Core architecture with slightly worse IPC but more cores per dollar.
                    Again, this is not true. Zen 2 has higher IPC than Intel cores and the single threaded performance lead of Intel is because of operating frequency (at a huge power cost):


                    Comment


                    • #50
                      Originally posted by Buntolo View Post
                      Does just disabling SMT/HT impact performances less than having it enabled + using mitigations?
                      LVI is a class of vulnerabilities [1], and most of them are not dependent on HT. The mitigation performance test from this article will be applied selectively to software and most likely not to the entire OS. Intel basically said that unless you use (write for) SGX you don't have to do anything because they think LVI is nearly unexploitable. Take that as you will

                      [1] - https://lviattack.eu/static/lvi-tree.svg (https://transient.fail/)

                      Comment

                      Working...
                      X