I am confused, doesn't this mean that Retpoline needs to sit in the compiler and won't protect from already-compiled binaries?
We deploy new code binaries all the time so it's not a big deal.
Something compiled with retpoline is resilient from it's execution being impacted. Once KVM is recompiled with retpoline, guests cannot attack it via spectre variant 2, and as such, cannot attack other guests.
The hypervisor being compiled with retpoline, however, does nothing to protect from intra-guest attacks - if you have untrusted code running in your VM, and you don't have IBRS and the other microcode features on, or your sensitive apps compiled with retpoline, you are still vulnerable internally. Just not from other guests
I am not super familiar with google’s offering but I suspect they don’t just offer VMs. Anything that runs in a shared infrastructure (serverless design/websites hosting) runs on top of a Linux box I presume. Google would need to get those Linux binaries recompiled too, not just the hypervisor.
We've already patched the host (for a long while now). You can also recompile your binaries in your guest, and/or get an updated kernel. retpoline performs much better than the brute force hammers you've seen reported.
https://pdos.csail.mit.edu/6.824/papers/borg.pdf
VMs and security sandboxing techniques are used to run external software by Google’s AppEngine (GAE) [38] and Google Compute Engine (GCE). We run each hosted VM in a KVM process [54] that runs as a Borg task.
There might be a few machines here and there running actual VMs on bare metal, but those are going to be very special cases. Using Infrastore, it's easy to find which teams are running which containers whose binaries were built before the new compiler defaults.
If the question is 'How do they guarantee their customers aren't using bad binaries', the answer is they don't, and has nothing to do with VMs vs VMs in containers, etc.
Running a VM in a Borg task (container) does not add extra security in this case, but it does help with auditing and catching the snowflakes and stragglers that invariably end up taking a disproportionate amount of time with changes like this. That kind of auditing can be easily done organization-wide, instead of having every team reinvent the wheel their own way.
KVM virtual machines making use of Extended Page Tables or Nested Page Tables do not share an address space with their host or other guests, however, they are susceptible to Spectre v2, for example. (This was the PZ PoC for variant 2)
It follows from what a cache is. You have a large set of numbers (memory addresses) mapping into a smaller set of numbers (cache lines); my necessity there will be a collision.
The mapping is deterministic and you can recover information by looking at these clashes.
Some intel high end CPUs have a feature called CAT which was designed to avoid that different workloads interfere too much by stomping on each other's cache lines, but I think it's meant mostly as a performance feature not a security feature (although there is some research about how to use it to defend from cache-based side channels, see http://palms.ee.princeton.edu/system/files/CATalyst_vfinal_c... and https://arxiv.org/pdf/1708.09538.pdf).
Another possible approach is to make it harder to predict the mapping between a physical address (or an address delta) and a cache line. I don't know if using a cryptographic-grade mapping for hardware cache would be even remotely feasible nor whether it would actually solve the problem of information leak.
(If it brings you any amusement: imagine speculative execution as an overly energetic 7-year old that we must now build a warehouse of trampolines around.) [1]
Thanks!