4 ms·
AWS Statement: Processor Speculative Execution Research Disclosure
- vosper 9y agoI 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.
- unclebucknasty 9y agoAgreed. Also this: >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?
- smn1234 9y agoI assume, per the shared responsibility model, this implies guest OS (your instance) requires you to patch. Underlying host, hypervisor, would be patched.
- _red 9y agoHow 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?
- CaliforniaKarl 9y agoIf 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.
- zwily 9y agoYou 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 agoInteresting. 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 agoThe 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 agoThanks for clarifying. The concepts are actually straightforward if I'm not being too lazy to check my assumptions!
- deleted 9y ago[deleted]
- deleted 9y ago[deleted]
- wahnfrieden 9y agoThis says operating systems must be patched. I don't see any notice from Ubuntu yet. Does this apply to upgrading Ubuntu as well?
- pfg 9y agoThe 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.
- perennate 9y agoThey have a wiki article now, https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAn...
- sparrish 9y agoI'm getting a 404 from that URL now.
- edwhitesell 9y agoI did on first attempt to load it, then it worked on an immediate refresh. Probably a cold cache or something.