Announcement

Collapse
No announcement yet.

Jon Masters On Understanding Spectre & Meltdown CPU Vulnerabilities

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

  • Jon Masters On Understanding Spectre & Meltdown CPU Vulnerabilities

    Phoronix: Jon Masters On Understanding Spectre & Meltdown CPU Vulnerabilities

    Arguably the most interesting keynote at this year's FOSDEM event was Red Hat's Jon Masters talking about the Spectre and Meltdown CPU vulnerabilities on an interesting technical level...

    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
    the fundamental matter to understand is which CPU's family are affected by these bugs. It seems that CPU based on FSB are immune from them, furthermore the other important matter to understand is if the PATCHES against these vulnerabilities will affect also the immune cpus.

    Comment


    • #3
      Interesting read, correct me if I am wrong here: There is currently no ProofOfConcept which does demonstrate Spectre outside an "in-process" scenario, eg.:



      The PoCs seem to be limited to "in-process" designs.

      Comment


      • #4
        Thanks for the link. It is quite interesting ...

        Comment


        • #5
          Originally posted by f.s.e View Post
          Interesting read, correct me if I am wrong here: There is currently no ProofOfConcept which does demonstrate Spectre outside an "in-process" scenario, eg.:

          While there's nothing stopping you from applying that same concept outside an "in-process" scenario, I'm afraid (or happy) that doing so might prove much harder, because you need to know details about the victim code/data and its location in memory (please correct me if I'm wrong).

          The difficulty of exploiting Spectre in real world scenarios is why I think that Meltdown and Spectre should be considered very different vulnerabilities and their public disclosure should have happened in separate documents and websites.
          Last edited by lucrus; 11 February 2018, 03:16 PM.

          Comment


          • #6
            Originally posted by Azrael5 View Post
            It seems that CPU based on FSB are immune from them,
            Huh, what ? I think you meant "CPU that do not speculatively execute". (Older in-order Intel Atoms ; Intel Xeon Phi on Intel MIC GPUs ; lots of older RISC CPUs)

            Originally posted by f.s.e View Post
            Interesting read, correct me if I am wrong here: There is currently no ProofOfConcept which does demonstrate Spectre outside an "in-process" scenario, eg.:

            The PoCs seem to be limited to "in-process" designs.
            Spectre variant 1 - "Boundary Check Bypass" (i.e. standard speculative execution)
            Yes, it's limited to in-process, by design of speculative execution.
            (The application is still accessing data that it should be accessing. The github code accesses a different memory array that lies outside the boundaries of the first array).

            Spectre variant 2 - "Branch Target Injection"
            Nope, it was actually sucessfully exploited by Google accross code which wasn't even running inside the same virtual machine (code running inside a virtual guest, managed to attack the kernel of the virtual host).

            Basic structure of the attack is :
            - attacker's code at some position does some indirect jumps at a specific target (jumps whose address isn't known in advance but computed).
            - in a completely different context (even a different virtual machine) there's an indirect jump.
            - the CPU thinks that both indirect jumps look a-like and start speculatively executing at the usual address where the attacker code jumps.
            - (eventually address is computed, speculative execution is cancelled, results are thrown away, real execution restarts at the correct position)
            - but until then speculative execution has executed pieces of code of the attacker's choosing. Code that would never be executed under normal circumstances.

            The PDF's slide that Michael has used to illustrate the article shows exactly that :
            - The attacker's process A at address 0x5000 has a jump instruction. The CPU learns where this instruction usually jumps to
            (in the PDF's slide: the CPU is taking note of a condition's result : True, False, etc. In Google's demo code, the CPU is taking note of a indirect jump destination. Difference explained on slide 54 of the PDF)
            - Another different victim process B (might even be kernel, hypervisor) has at address 0x5000 a jump instruction.
            - the CPU confuse them both (in the PDF's slide: ...because the CPU only store the lower 3 nibble "0x000" and they are exactly the same.
            In Google's demo code : real-world Intel Xeon CPUs store the lowerbits of the address and a hash of the higherbits. It's possible to create a collision of this.)
            - thus the confused CPU uses what it has learned from the wrong program A.
            (In the PDF's slide: it would speculate based on the "TTNNTTNN" information that should normally be used for program A, instead of whatever would have been the correct information for program B.
            In Google's demo code, the CPU speculatively jumps to the address where look-a-like program A usually jumps to, thus ending up running bits of the hyper visor that would not normally be called - "gadgets" in the return-oriented-programming).

            Note that, unlike the above v1 which is common to any CPU doing speculative execution and is basically speculative execution going according to manual,
            v2 is *extremely* dependent on the CPU - more precisely on how the CPU saves its prediction information and on how it could be confused.
            (It's also dependent on the target you want to attack. There should be some interesting "gadget" to speculatively jump to. If you know the exact layout of the hypervisor (using a specific debian version in Google's demo code) you can manage to execute a gadget that will leak informations. But if your target application is "fortune" good luck in succeeding any interesting leak).

            Currently it has been only demoed on a specific model of Intel Xeon. More Intel CPU should be vulnerable. (But not all with the same trick).

            AMD thinks that their CPU are vulnerable (they do speculative execution of indirect branches) but that it would be extremely difficult to actually manage to write an exploit (the speculation works in a completely different manner. You can't use the "re-use the low bit part" trick that works against affected Intel CPUs - google's demo code won't work for obvious reasons).
            Indeed, there's no known successful exploit yet.

            (Also the current demo code by google is written for a specific virtual host. If you want to re-use the same exploit against Amazon's Cloud or Microsoft's Azure, you would need to know what those are running as virtual host, and thus poison the indirect branch prediction with different target addresses)

            Comment


            • #7
              Thanks for sharing, Michael.

              Jon Masters is a phenomenal person and an awesome tech guru, IMHO.

              Comment


              • #8
                DrYak I've asked many people and consulted forums which state that cpus base on fsb are immune from those bugs. Is it real or not?
                Last edited by Azrael5; 06 February 2018, 07:12 AM.

                Comment


                • #9
                  Originally posted by Azrael5 View Post
                  DrYak I've asked many people and consukted forums which state that cpus base on fsb are immune from those bugs. Is it real or not?
                  That's not real. A FSB has nothing to do with these bugs. The only plausible thing I see connecting them is that the original Atom CPUs used a FSB (because it was cheap and old tech) and isn't affected - but that's because it was an in-order design (also because it was cheap and old). Plenty of FSB using CPUs like the Pentium 4 are absolutely at risk for these bugs, because they use speculative execution.

                  Comment


                  • #10
                    Originally posted by DrYak View Post
                    Spectre variant 1 - "Boundary Check Bypass" (i.e. standard speculative execution)
                    Yes, it's limited to in-process, by design of speculative execution.
                    (The application is still accessing data that it should be accessing. The github code accesses a different memory array that lies outside the boundaries of the first array).
                    In practice, it seems SV1 is not easily fixed by microcode alone (and rather will never be done for all of Intel and AMD), plus there wont be a simple, global switch to turn off the spec. execution and willingly taking the performance hit? So its recompile the code correctly, with some workaround like LFENCE. On all very recent Linux Dists. and Win. tested and microcodes, AMD and Intel still fall for the simple SV1PoCs on GitHub.

                    Thanks for the excellent write-up, DrYak.

                    Comment

                    Working...
                    X