From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org, quintela@redhat.com
Subject: Re: [Qemu-devel] [qemu-web PATCH] refine spectre blog post
Date: Fri, 5 Jan 2018 10:42:18 +0000 [thread overview]
Message-ID: <20180105104217.GC2491@work-vm> (raw)
In-Reply-To: <20180105103843.30526-1-pbonzini@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 <dgilbert@redhat.com>
> Suggested-by: Juan Quintela <quintela@redhat.com>
> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
> ---
> _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 <dgilbert@redhat.com>
> 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
next prev parent reply other threads:[~2018-01-05 10:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-05 10:38 [Qemu-devel] [qemu-web PATCH] refine spectre blog post Paolo Bonzini
2018-01-05 10:42 ` Dr. David Alan Gilbert [this message]
2018-01-05 10:46 ` Juan Quintela
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=20180105104217.GC2491@work-vm \
--to=dgilbert@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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.