QEMU and the Spectre and Meltdown attacks
As you probably know by now, three critical architectural flaws in CPUs have been recently disclosed that allow user processes to read kernel or hypervisor memory through cache side-channel attacks. These flaws, collectively named Meltdown and Spectre, affect in one way or another almost all processors that perform out-of-order execution, including x86 (from Intel and AMD), POWER, s390 and ARM processors.
No microcode updates are required to block the Meltdown attack. In addition, the Meltdown flaw does not allow a malicious guest to read the contents of hypervisor memory. Fixing it only requires that the operating system separates the user and kernel address spaces (known as page table isolation for the Linux kernel), which can be done separately on the host and the guests. Therefore, this post will focus on Spectre, and especially on CVE-2017-5715.
Fixing or mitigating Spectre in general, and CVE-2017-5715 in particular, requires cooperation between the processor and the operating system kernel or hypervisor; the processor can be updated through microcode or millicode patches to provide the required functionality.
Among the three vulnerabilities, CVE-2017-5715 is notable because it allows guests to read potentially sensitive data from hypervisor memory. Patching the host kernel is sufficient to block attacks from guests to the host. On the other hand, in order to protect the guest kernel from a malicious userspace, updates are also needed to the guest kernel and, depending on the processor architecture, to QEMU.
Just like on bare-metal, the guest kernel will use the new functionality provided by the microcode or millicode updates. When running under a hypervisor, processor emulation is mostly out of QEMU’s scope, so QEMU’s role in the fix is small, but nevertheless important. In the case of KVM:
-
QEMU configures the hypervisor to emulate a specific processor model. For x86, QEMU has to be aware of new CPUID bits introduced by the microcode update, and it must provide them to guests depending on how the guest is configured.
-
upon virtual machine migration, QEMU reads the CPU state on the source and transmits it to the destination. For x86, QEMU has to be aware of new model specific registers (MSRs).
Right now, there are no public patches to KVM that expose the new CPUID bits and MSRs to the virtual machines, therefore there is no urgent need to update QEMU; remember that updating the host kernel is enough to protect the host from malicious guests. Nevertheless, updates will be posted to the qemu-devel mailing list in the next few days, and a 2.11.1 patch release will be released with the fix.
Once updates are provided, live migration to an updated version of QEMU will not be enough to protect guest kernel from guest userspace. Because the virtual CPU has to be changed to one with the new CPUID bits, the guest will have to be restarted.
As of today, the QEMU project is not aware of whether similar changes will be required for non-x86 processors. If so, they will also be posted to the mailing list and backported to recent stable releases.
For more information on the vulnerabilities, please refer to the Google Security Blog and Google Project Zero posts on the topic, as well as the Spectre and Meltdown FAQ.
5 Jan 2018: clarified the level of protection provided by the host kernel update; added a note on live migration; clarified the impact of Meltdown on virtualization hosts