Announcement

Collapse
No announcement yet.

Google Engineer Uncovers Holes In Linux's Speculative Execution Mitigations

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

  • Google Engineer Uncovers Holes In Linux's Speculative Execution Mitigations

    Phoronix: Google Engineer Uncovers Holes In Linux's Speculative Execution Mitigations

    There are some urgent fixes pending for the x86/x86_64 speculative execution handling for the Linux kernel following a Google security engineer discovering these issues, including one of the fixes address a situation that unfairly impacted AMD CPUs...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Maybe some new benchmark will be in order as well?

    Comment


    • #3
      If I understood the explanation well, the performance impact on AMD CPUs would be only in the case of disabled SMT, so it would affect all pre-Zen?

      Comment


      • #4
        First up is an issue over force disabling IBPB based on STIBP and enhanced IBRS.
        i am likely too dumb for this article, but adding some explanations would not hurt.

        Comment


        • #5
          So, those of us who said early on that all these mitigations are just going to open up their own security holes were not wrong. Shocking.

          I for one welcome our new mitigations-of-the-mitigations overlords.

          Comment


          • #6
            Originally posted by andyprough View Post
            So, those of us who said early on that all these mitigations are just going to open up their own security holes were not wrong. Shocking.

            I for one welcome our new mitigations-of-the-mitigations overlords.
            Indeed. Broken hardware with broken ass solutions which we barely understand the consequences of.

            Comment


            • #7
              Does anyone know if this has something to due with the latest QEMU/Libvirt host-passthrough problems with Ryzen and STIBP?

              Both QEMU and libvirt changed around the same time, and shortly thereafter I found that host-passthrough no longer worked in any of my four Windows 10 VMs (even those with no passthrough components). After about a month I discovered that the problem was having STIBP enabled, so now I actually have to manually add a feature to libvirt so I can disable it in the VM XML.

              For anyone else with the same problem just add the following to /usr/share/libvirt/cpu_map/x86_features.xml:

              <feature name='amd-stibp'>
              <cpuid eax_in='0x80000008' ebx='0x00008000'/>
              </feature>

              And then add the following to the VM XML <cpu> block:
              <cpu>
              <feature policy="disable" name="amd-stibp"/>
              </cpu>

              Comment


              • #8
                I wonder what explanation(s) will be used by Linux kernel developers regarding these bugs in their highly vaunted (suspect?) mitigation code:
                • the sound of crickets chirping (in other words, "No comment at all")
                • "These CPU issues were so critical that we had to get something out there to mitigate it. So we're not surprised there are bugs."
                • "Hey! We volunteer our time to Linux development. If somebody paid us, and there's a bug report on it, we would try to fix our code."
                • "Hey! We volunteer our time to Linux development. If somebody paid us to write this code we might write better, more bug-free code."
                • "There are issues with AMD processors? Well, if AMD would be more timely in providing their specs we could write better code for that hardware."
                • [your thoughts go here]

                Comment


                • #9
                  Originally posted by andyprough View Post
                  So, those of us who said early on that all these mitigations are just going to open up their own security holes were not wrong. Shocking.
                  no, you were still wrong. these aren't "their own security holes". these are just gaps in the mitigations that allow people to exploit the underlying flaws that the mitigations are supposed to protect against in certain circumstances. you're significantly safer with mitigations than without them.

                  Comment


                  • #10
                    NotMine999 How many of them are really volunteer anymore.. Linux isn't exactly a hobbyist OS now days..

                    I think this has to do more with the kernel teams definition of security bugs and how they treat them.

                    Comment

                    Working...
                    X