Announcement

Collapse
No announcement yet.

GNU Assembler Adds New Options For Mitigating Load Value Injection Attack

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

  • GNU Assembler Adds New Options For Mitigating Load Value Injection Attack

    Phoronix: GNU Assembler Adds New Options For Mitigating Load Value Injection Attack

    Yesterday the Load Value Injection (LVI) vulnerability was disclosed by Intel and researchers and affecting newer Intel CPUs with SGX and requiring mitigations outside of all the speculative execution mitigations the past two years. The GNU Assembler patches adding new options for mitigation have now been merged to Git master...

    http://www.phoronix.com/scan.php?pag...er-LVI-Options

  • #2
    ...this is a never ending story. I would like to know which of this corporate cheapskates are responsible for this "performance over security" paradigm...just imagine for a second if this would be some diesel powered car.

    Comment


    • #3
      lfence after loads. lfence after indirect branch. lfence before ret.
      Brilliant. Why not just serialize the entire pipeline while we are at it?
      Even if you manage to track susceptible gadgets, chances you're going to miss a lot of them.
      This type of mitigation is going to shoot performance to bits if applied liberally.

      Really. Hallmarks of a real shit show taken to the next level.

      Comment


      • #4
        Originally posted by CochainComplex View Post
        I would like to know which of this corporate cheapskates are responsible for this "performance over security" paradigm...
        Every user who wanted 100% performance increases every 18 months for the past 49 years. Moore's law - ain't it beautiful?

        Comment


        • #5
          Originally posted by andyprough View Post

          Every user who wanted 100% performance increases every 18 months for the past 49 years. Moore's law - ain't it beautiful?
          but even that wasn't delivered Since competition from Red Team is back it seems to work again - larger performance leaps.
          In this regard I should have written "profit over security". Intel had years of easy going - high profit margins with modest demand of more performance because there was no competitor. You can not tell me that Intel was under pressure - now they are and still they are profitable with huge discounts on cpu's and high expenses on the <10nm node technology. The whole laptop market shares are in their basket.
          No, I would understand this argument for IBM with Power CPU's or even AMD just barely above extinction (2017)...but common this issue is not because intel has bad engineers and QA or because they had to push something ...no it is because some guys thought it would be great to squeze out the last pennys in the R&D Department.

          Comment


          • #6
            Originally posted by andyprough View Post

            Every user who wanted 100% performance increases every 18 months for the past 49 years. Moore's law - ain't it beautiful?
            Wait a sec. I think we have been using 4 core processors for about ten years.

            Comment


            • #7
              Originally posted by zxy_thf View Post
              Wait a sec. I think we have been using 4 core processors for about ten years.
              After each desktop TIC / TOK
              Intel managers: Increase IPC, don't increase cores or PCIe lanes!
              Intel engineers: Ah sh*t, here we go again.
              Intel managers: And don't you dare spend time on security, ain't nobody got time for that!

              Comment


              • #8
                would -mlfence-before-indirect-branch and -mlfence-before-ret even do anything to mitigate the vulnerability? isn't the problem with indirect branches that they do a load and then branch based on the loaded value without any opportunity to put an lfence in between? I thought the only way to mitigate those was to replace them with sequences of load, lfence, then direct branch.

                Comment


                • #9
                  Originally posted by Jabberwocky View Post

                  After each desktop TIC / TOK
                  Intel managers: Increase IPC, don't increase cores or PCIe lanes!
                  Intel engineers: Ah sh*t, here we go again.
                  Intel managers: And don't you dare spend time on security, ain't nobody got time for that!
                  I think the hubris here is in the form of "You can't hack CPUs" - with that mindset the engineers developed the uArch. Attitudes changed over time, but developing a new uArch is a multi year, multi billion effort of which I am sure that Intel is currently in the midst of.

                  Comment


                  • #10
                    Originally posted by andyprough View Post

                    Every user who wanted 100% performance increases every 18 months for the past 49 years. Moore's law - ain't it beautiful?
                    Moore's law isn't about performance, it's about doubling transistor count in the same area. The performance increase was just a side effect. You can start treating it as such.

                    Comment

                    Working...
                    X