Announcement

Collapse
No announcement yet.

Linux Kernel Patched For "PBRSB" After Intel eIBRS CPUs Found To Be Insufficient

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

  • Linux Kernel Patched For "PBRSB" After Intel eIBRS CPUs Found To Be Insufficient

    Phoronix: Linux Kernel Gets Patched For "PBRSB" After Intel eIBRS CPUs Found To Be Insufficient

    Today's busy patch Tuesday for Intel continues with the Linux kernel getting mitigated for EIBRS Post-barrier Return Stack Buffer (PBRSB). This PBRSB is the latest handling on the "CPU vulnerability nightmares front", the pull request calls it...

    https://www.phoronix.com/news/Linux-PBRSB-Mitigation

  • #2
    Just a few days ago, 5.18.15 included some changes related to retbleed that enabled IBPB in CPU that didn't have it (particularly older AMD models, as in the Bulldozer family just before Ryzen, so not so old!), therefore preventing the affected systems to boot. The issue was quickly addressed and fixed, but that kind of patches and with so many mitigations to account for nowadays... It is better to wait a bit if upgrading kernels after today's disclosure!

    Comment


    • #3
      Michael Would it be possible to test the mitigation performance impact on workloads running in virtual machines?
      Preferably with both host and guest mitigation combinations. This issue is quite complicated because QEMU/KVM CPU mitigation flags are not turned on by default.
      A comparison to native runs on the same hardware would be awesome as well, but that would generate many test cases.

      Comment


      • #4
        eIBRS found insufficient.
        Well, I'll be ...... Color me surprised (yes, irony).

        So nope. Still everything disabled until the dust from this godforsaken mess settles a bit.

        Comment


        • #5
          Unless you are a cloud provider, say no to this ever ending madness with mitigations=off

          Comment


          • #6
            Damn.. old desktop CPUs are slowly becoming paperweight. This might provide some insights on post-mitigations desktop performance as well: https://www.phoronix.com/review/xeon-skylake-retbleed
            My guess is, Skylake era ultrabooks users will soon find it difficult to even browse the web or use high productivity applications such as Teams or VS Code.

            Comment


            • #7
              Originally posted by caligula View Post
              Damn.. old desktop CPUs are slowly becoming paperweight. This might provide some insights on post-mitigations desktop performance as well: https://www.phoronix.com/review/xeon-skylake-retbleed
              My guess is, Skylake era ultrabooks users will soon find it difficult to even browse the web or use high productivity applications such as Teams or VS Code.
              Yeah. I refurbish a lot of old hardware, and all modern Linux distros just slowing down on old hardware, across the board, from Debian to Mint, from 32-bit Linux 4 kernel, to newest 64-bit Linux 5 kernels. Its not just modern GUI, I guess mitigations plays the part. Security comes with performance cost.

              Comment


              • #8
                Originally posted by bobbie424242 View Post
                Unless you are a cloud provider, say no to this ever ending madness with mitigations=off
                Not if you're using the computer to browse the Internet. You're running even more untrusted code (every website you visit you didn't personally write) than cloud and virtualized infrastructures are.

                Lax hardware security is coming home to roost. Security researchers have been warning about the fallout for awful hardware security attention for decades, and more so since around 2010 when language security began to get more public attention. It is mathematically impossible for a system running Turing complete computer languages to ever have 100% accurate predictive algorithms to allow speculative execution without exploitation of the situation. No amount of mitigations will solve this problem. It's just throwing more fuel on the bonfire every iteration.

                I don't have the answer to the problem other than abandoning speculative execution entirely if you need more security.

                Comment


                • #9
                  I browse the internet, but of course I use a script blocker.

                  Comment


                  • #10
                    Originally posted by stormcrow View Post

                    Not if you're using the computer to browse the Internet. You're running even more untrusted code (every website you visit you didn't personally write) than cloud and virtualized infrastructures are.
                    .
                    all browsers have built-in mitigations by now.

                    Comment

                    Working...
                    X