4 ms·

You need to patch your VM to prevent your own processes exploiting the bug. The hyper visor patch is to protect you from the other VMs on the box.

• unclebucknasty 9y ago
  Interesting. I'd assumed the performance degredation resulted from disabling the offending cpu optimization feature at the hardware/firmware level, which would seem to address the issue for anything on the box (vm and hypervisor). But, perhaps that assumption was wrong and/or Amazon has another workaround.
  • zeta0134 9y ago
    The confusion is perhaps understood, as this is a complex issue. Basically, you need to remember that on the hypervisor there are two kernels; the hypervisor's OS, and the Guest's OS. The exploit works, we assume, by abusing shared memory between the kernel and userland process to allow the userland process to read memory that it shouldn't be able to see. The mitigation moves kernel memory out of the MMU entirely when making the switch. If the hypervisor has the patch, but the Guest OS does not, it means that when the hypervisor context-switches into the Guest OS, it'll move its own kernel memory out of range of the exploit. So far so good. But the Guest OS is un-patched; when its kernel context switches into a userland process, its own kernel memory space remains available for the exploit. Thus, a patched hypervisor can protect itself, but not its guests.
    • unclebucknasty 9y ago
      Thanks for clarifying. The concepts are actually straightforward if I'm not being too lazy to check my assumptions!