I hoped they might discuss the supposed decrease in performance that the patches introduce (I imagine they did some testing) but I guess they're leaving it up to their users to discover whether their instances are slower now.
>All but a small single-digit percentage of instances across the Amazon EC2 fleet are already protected.
As of when?
Goes on to say that the "underlying infrastructure" is protected, but OS patches are required. What does it mean that instance infrastructure is protected, but the OS is not, and which step would introduce the performance degradation?
I assume, per the shared responsibility model, this implies guest OS (your instance) requires you to patch. Underlying host, hypervisor, would be patched.
How would that work? unpatched VM can escape the patched Hypervisor? Is that possible? What would be point of patching hypervisor if guest can trivially escape?
If I remember correctly, this bug only comes under AWS’ responsibility when people are using paravirtualized instances. HVM instance’s don’t have a Linux kernel below your OS, so they don’t need underlying work, they just need OS patching.
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.
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.
The vulnerabilities affect multiple layers in a virtualized environment. Amazon patching the virtualization host is what would prevent things like guests reading host memory (essentially a guest escape - one VM gaining access to other VMs running on the same system). Patching the guest VM is what's needed to mitigate other attack vectors (like unprivileged code reading kernel memory).
I don't think updated packages are available for any of the major distributions as of now. So far I've only seen fixed packages for Amazon Linux and Google's Container-Optimized OS.
16 comments
[ 3.2 ms ] story [ 50.0 ms ] thread>All but a small single-digit percentage of instances across the Amazon EC2 fleet are already protected.
As of when?
Goes on to say that the "underlying infrastructure" is protected, but OS patches are required. What does it mean that instance infrastructure is protected, but the OS is not, and which step would introduce the performance degradation?
But, perhaps that assumption was wrong and/or Amazon has another workaround.
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.
I don't think updated packages are available for any of the major distributions as of now. So far I've only seen fixed packages for Amazon Linux and Google's Container-Optimized OS.