4 ms·
The replies are missing something from the original article. They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This me
by rocqua 9y ago
The replies are missing something from the original article.
They are running on the cloud, and Meltdown / spectre means that exploits can escape a VM. This means you don't just need to trust your VM, but also any VMs you are sharing the hardware with.
- Asdfbla 9y agoI suppose if a Cloud provider could ensure that all your VM instances run on the same host and no other VM is allowed there then the issue would be a bit mitigated. Although this restriction on how the cloud provider is allowed to schedule your VMs probably would somewhat defeat the point of cloud hosting in the first place. Out of curiosity, how many VM/container instances usually run on a physical host at any given time (for your typical cloud computing provider)?
- asheldon 9y agoAWS provides the ability to guarantee you don't share physical hardware with other customers with "EC2 Dedicated Instances" (https://aws.amazon.com/ec2/purchasing-options/dedicated-instances/ https://aws.amazon.com/ec2/purchasing-options/dedicated-inst...). I'm not familiar enough with other cloud provider offerings to say if they do or do not have similar features.
- Fargren 9y agoWith AWS, and I assume most other cloud computing providers, you can pay extra for you instances to run in a host without someone else's VMs. You probably should be doing this for any servers were you handle sensitive data, but it is a place were many will be cutting corners.
- mrep 9y agoYou don't really even have to pay extra. Just use the biggest instance since and you are guaranteed to be isolated because there is no room for anyone else. Granted, that only works for workloads that are spread across enough small instances.
- bonzini 9y agoOnly Spectre CVE-2017-5715 can escape a VM, not Meltdown. Even then, you don't need to trust your co-tenants. Updating the host (which your provider has already done, or which is anyway out of your control) is both necessary and sufficient to protect from VM escapes.
- mwarkentin 9y agoI think it’s the other way around.. and the host updates are what have been introducing these performance hits as well.
- bonzini 9y agoWhat is the other way round? (I worked on the fixes for Red Hat).
- yborg 9y agoI think he's saying that unpatched, a co-resident VM can compromise the host even if you are locally patched. If the host is patched this doesn't matter (for VM escapes); however, for those on public clouds that will apply the host patching globally, you will be eating the performance degradation whether or not your workload cares about it. I don't think AWS et al will be offering a "run unpatched instance" option. Or maybe they will, this looks pretty devastating for some workloads; on the other hand, cloud providers could actually end up making a lot of money from this issue...
- bonzini 9y agoNo, that is not the case. The hypervisor is able to protect myself from unpatched guests, at a performance cost of course...