On Thu, Jan 04, 2018 at 06:56:09PM +0100, Paolo Bonzini wrote: > --- > _posts/2018-01-04-spectre.md | 60 > ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 60 insertions(+) > create mode 100644 _posts/2018-01-04-spectre.md
Thanks for writing it up! Reviewed-by: Eduardo Habkost <ehabk...@redhat.com> > > diff --git a/_posts/2018-01-04-spectre.md b/_posts/2018-01-04-spectre.md > new file mode 100644 > index 0000000..1be86d0 > --- /dev/null > +++ b/_posts/2018-01-04-spectre.md > @@ -0,0 +1,60 @@ > +--- > +layout: post > +title: "QEMU and the Spectre and Meltdown attacks" > +date: 2018-01-04 18:00:00 +0000 > +author: Paolo Bonzini and Eduardo Habkost > +categories: [meltdown, spectre, security, x86] > +--- > +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; it is > +enough to update the guest operating system to a version that separates > +the user and kernel address spaces (known as _page table isolation_ for > +the Linux kernel). Therefore, this post will focus on _Spectre_, and > +especially on > [CVE-2017-5715](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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. CVE-2017-5715 allows guests > +to read potentially sensitive data from hypervisor memory; however, > __patching > +the host kernel is sufficient to block this attack__. > + > +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. > + > +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 posted to the > +mailing list and backported to recent stable releases. > + > +For more information on the vulnerabilities, please refer to the [Google > Security > +Blog](https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html) > +and [Google Project > +Zero](https://googleprojectzero.blogspot.it/2018/01/reading-privileged-memory-with-side.html) > +posts on the topic, as well as the [Spectre and Meltdown > FAQ](https://meltdownattack.com/#faq). > -- > 2.14.3 > -- Eduardo
