
AWS Statement: Processor Speculative Execution Research Disclosure - bryanh
https://aws.amazon.com/security/security-bulletins/AWS-2018-013/
======
vosper
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.

~~~
unclebucknasty
Agreed. 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
I assume, per the shared responsibility model, this implies guest OS (your
instance) requires you to patch. Underlying host, hypervisor, would be
patched.

~~~
_red
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?

~~~
zwily
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
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
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
Thanks for clarifying. The concepts are actually straightforward if I'm not
being too lazy to check my assumptions!

------
wahnfrieden
This says operating systems must be patched. I don't see any notice from
Ubuntu yet. Does this apply to upgrading Ubuntu as well?

~~~
pfg
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.

------
sparrish
I'm getting a 404 from that URL now.

~~~
edwhitesell
I did on first attempt to load it, then it worked on an immediate refresh.
Probably a cold cache or something.

