From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXPSH-00008W-7Q for qemu-devel@nongnu.org; Fri, 05 Jan 2018 05:42:30 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXPSC-0001Yr-O6 for qemu-devel@nongnu.org; Fri, 05 Jan 2018 05:42:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40358) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eXPSC-0001Xv-CU for qemu-devel@nongnu.org; Fri, 05 Jan 2018 05:42:24 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7E41A5D68C for ; Fri, 5 Jan 2018 10:42:23 +0000 (UTC) Date: Fri, 5 Jan 2018 10:42:18 +0000 From: "Dr. David Alan Gilbert" Message-ID: <20180105104217.GC2491@work-vm> References: <20180105103843.30526-1-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180105103843.30526-1-pbonzini@redhat.com> Subject: Re: [Qemu-devel] [qemu-web PATCH] refine spectre blog post List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org, quintela@redhat.com * Paolo Bonzini (pbonzini@redhat.com) wrote: > People were confused about the level of protection provided by host kernel > updates (which do not exist yet, but I digress). They were also asking > whether it will be possible to live migrate from old to new QEMU and get > the fixes. Clarify both aspects. > > Suggested-by: Dr. David Alan Gilbert > Suggested-by: Juan Quintela > Signed-off-by: Paolo Bonzini > --- > _posts/2018-01-04-spectre.md | 32 +++++++++++++++++++++----------- > 1 file changed, 21 insertions(+), 11 deletions(-) > > diff --git a/_posts/2018-01-04-spectre.md b/_posts/2018-01-04-spectre.md > index 1be86d0..5bbc7ed 100644 > --- a/_posts/2018-01-04-spectre.md > +++ b/_posts/2018-01-04-spectre.md > @@ -2,6 +2,7 @@ > layout: post > title: "QEMU and the Spectre and Meltdown attacks" > date: 2018-01-04 18:00:00 +0000 > +last_modified_at: 2018-01-05 10:30:00 +0000 > author: Paolo Bonzini and Eduardo Habkost > categories: [meltdown, spectre, security, x86] > --- > @@ -21,17 +22,19 @@ especially on [CVE-2017-5715](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE > 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: > +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: OK, that looks clearer to me. > * 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 > @@ -49,6 +52,10 @@ 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 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. OK. Reviewed-by: Dr. David Alan Gilbert > 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. > @@ -58,3 +65,6 @@ Blog](https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you- > 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). > + > +__5 Jan 2018__: clarified the level of protection provided by the host kernel > +update; added a note on live migration. > -- > 2.14.3 > -- Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK