From patchwork Thu Jan 4 18:13:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexandre DERUMIER X-Patchwork-Id: 10145337 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 5C25760594 for ; Thu, 4 Jan 2018 18:24:17 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 4EE872882F for ; Thu, 4 Jan 2018 18:24:17 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 43C032877B; Thu, 4 Jan 2018 18:24:17 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6AEFC2877B for ; Thu, 4 Jan 2018 18:24:16 +0000 (UTC) Received: from localhost ([::1]:58598 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXABb-0007Mb-Ab for patchwork-qemu-devel@patchwork.kernel.org; Thu, 04 Jan 2018 13:24:15 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52524) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eXAAF-00061T-5d for qemu-devel@nongnu.org; Thu, 04 Jan 2018 13:22:52 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eXAAC-0007yA-0E for qemu-devel@nongnu.org; Thu, 04 Jan 2018 13:22:51 -0500 Received: from mailpro.odiso.net ([89.248.211.110]:32784) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eXAAB-0007xK-Mg for qemu-devel@nongnu.org; Thu, 04 Jan 2018 13:22:47 -0500 Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id 3BD861E7D388; Thu, 4 Jan 2018 19:13:43 +0100 (CET) Received: from mailpro.odiso.net ([127.0.0.1]) by localhost (mailpro.odiso.net [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id opnOy3jrM-F7; Thu, 4 Jan 2018 19:13:43 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailpro.odiso.net (Postfix) with ESMTP id 202E71E7D389; Thu, 4 Jan 2018 19:13:43 +0100 (CET) X-Virus-Scanned: amavisd-new at mailpro.odiso.com Received: from mailpro.odiso.net ([127.0.0.1]) by localhost (mailpro.odiso.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iPlnJB3p-yM2; Thu, 4 Jan 2018 19:13:43 +0100 (CET) Received: from mailpro.odiso.net (mailpro.odiso.net [10.1.31.111]) by mailpro.odiso.net (Postfix) with ESMTP id 0C4761E7D388; Thu, 4 Jan 2018 19:13:43 +0100 (CET) Date: Thu, 4 Jan 2018 19:13:43 +0100 (CET) From: Alexandre DERUMIER To: pbonzini Message-ID: <87448218.845975.1515089623014.JavaMail.zimbra@oxygem.tv> In-Reply-To: <20180104175609.9085-1-pbonzini@redhat.com> References: <20180104175609.9085-1-pbonzini@redhat.com> MIME-Version: 1.0 X-Mailer: Zimbra 8.7.0_GA_1659 (ZimbraWebClient - GC63 (Linux)/8.7.0_GA_1659) Thread-Topic: add a blog post about "Spectre" Thread-Index: p5Gy1ReIBKxxACBK4UNpq7G7OK87bQ== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 89.248.211.110 Subject: Re: [Qemu-devel] [qemu-web PATCH] add a blog post about "Spectre" X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: qemu-devel , ehabkost Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP Thanks Paolo ! Do we need to update guest kernel too, if qemu use cpumodel=qemu64 ? (For example, I have some very old guests where kernel update is not possible) Regards, Alexandre ----- Mail original ----- De: "pbonzini" À: "qemu-devel" Cc: "ehabkost" Envoyé: Jeudi 4 Janvier 2018 18:56:09 Objet: [Qemu-devel] [qemu-web PATCH] add a blog post about "Spectre" --- _posts/2018-01-04-spectre.md | 60 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 _posts/2018-01-04-spectre.md 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).