From: Alexandre DERUMIER <aderumier@odiso.com>
To: pbonzini <pbonzini@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, ehabkost <ehabkost@redhat.com>
Subject: Re: [Qemu-devel] [qemu-web PATCH] add a blog post about "Spectre"
Date: Thu, 4 Jan 2018 19:13:43 +0100 (CET) [thread overview]
Message-ID: <87448218.845975.1515089623014.JavaMail.zimbra@oxygem.tv> (raw)
In-Reply-To: <20180104175609.9085-1-pbonzini@redhat.com>
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" <pbonzini@redhat.com>
À: "qemu-devel" <qemu-devel@nongnu.org>
Cc: "ehabkost" <ehabkost@redhat.com>
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).
--
2.14.3
next prev parent reply other threads:[~2018-01-04 18:22 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 17:56 [Qemu-devel] [qemu-web PATCH] add a blog post about "Spectre" Paolo Bonzini
2018-01-04 17:59 ` Paolo Bonzini
2018-01-04 18:01 ` Eduardo Habkost
2018-01-04 18:13 ` Alexandre DERUMIER [this message]
2018-01-04 18:17 ` Paolo Bonzini
2018-01-04 20:37 ` Stefan Hajnoczi
2018-01-09 2:13 ` Fam Zheng
2018-01-09 8:37 ` Paolo Bonzini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87448218.845975.1515089623014.JavaMail.zimbra@oxygem.tv \
--to=aderumier@odiso.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.