Re: [Qemu-devel] [qemu-web PATCH] Add a blog post documenting Spectre/Meltdown options for QEMU 2.11.1

[Bruce Rogers]

On 2/13/2018 at 5:11 PM, Michael Roth <address@hidden> wrote:
> This blog entry is intended as a follow‑up to the original entry in
> January regarding Spectre/Meltdown and the proposed changes to address
> them in the upcoming 2.11.1 release.
> 
> This entry is meant to accompany the 2.11.1 release (planned for
> 2018‑02‑14) and document how to make use of the new options for
> various architectures.
> 
> Cc: Eduardo Habkost <address@hidden>
> Cc: Paolo Bonzini <address@hidden>
> Cc: Peter Maydell <address@hidden>
> Cc: Suraj Jitindar Singh <address@hidden>
> Cc: David Gibson <address@hidden>
> Cc: Christian Borntraeger <address@hidden>
> Cc: Cornelia Huck <address@hidden>
> Cc: Thomas Huth <address@hidden>
> Signed‑off‑by: Michael Roth <address@hidden>
> ‑‑‑
> 
> The pseries/s390 bits have gotten some initial review (thanks 
> Suraj/Christian),
> but it can definitely use some additional review on the x86 side of things.
> 
> Also, Peter if think anything extra should to be mentioned on the ARM side 
> just
> let me know what to add.
> 
>  .../2018‑02‑14‑qemu‑2‑11‑1‑and‑spectre‑update.md   | 180 
> +++++++++++++++++++++
>  1 file changed, 180 insertions(+)
>  create mode 100644 _posts/2018‑02‑14‑qemu‑2‑11‑1‑and‑spectre‑update.md
> 
> diff ‑‑git a/_posts/2018‑02‑14‑qemu‑2‑11‑1‑and‑spectre‑update.md 
> b/_posts/2018‑02‑14‑qemu‑2‑11‑1‑and‑spectre‑update.md
> new file mode 100644
> index 0000000..7cdea59
> ‑‑‑ /dev/null
> +++ b/_posts/2018‑02‑14‑qemu‑2‑11‑1‑and‑spectre‑update.md
> @@ ‑0,0 +1,180 @@
> +‑‑‑
> +layout: post
> +title:  "QEMU 2.11.1 and making use of Spectre/Meltdown mitigation for KVM 
> guests"
> +date: 2018‑02‑14 10:35:44 ‑0600
> +author: Michael Roth
> +categories: [meltdown, spectre, security, x86, ppc, s390, releases, 'qemu 
> 2.11']
> +‑‑‑
> +
> +In a [previous post](https://www.qemu.org/2018/01/04/spectre/) it was
> +detailed how QEMU/KVM might be affected by Spectre/Meltdown attacks, and 
> what
> +the plan was to mitigate them in QEMU 2.11.1 (and eventually QEMU 2.12).
> +
> +QEMU 2.11.1 is now available, and contains the aforementioned mitigations 
> for
> +x86 guests, along with additional mitigation functionality for pseries and
> +s390 guests (ARM guests do not currently require additional QEMU patches).
> +However, enabling this functionality requires additional configuration 
> beyond
> +just updating QEMU, which we hope to address with this post.
> +
> +Please note that, as mentioned in the previous blog post, QEMU/KVM 
> generally
> +has the same requirements as other unpriviledged processes running on the
> +host WRT Spectre/Meltdown mitigation. What is being addressed here is
> +enabling a guest operating system to enable the same (or similar) 
> mitigations
> +to protect itself from unpriviledged guest processes. Thus, the
> +patches/requirements listed here are specific to that goal and should not 
> be
> +regarded as the full set of requirements to enable mitigations on the host
> +side (though in some cases there is some overlap between the two WRT 
> required
> +patches/etc).
> +
> +Also please note that this is a best‑effort from the QEMU/KVM community, and
> +these mitigations rely on a mix of additional kernel/firmware/microcode
> +updates that are in some cases not available publically, or may not yet be
> +implemented in some distros, so users are highly encouraged to consult with
> +their respective vendors/distros to confirm whether all the required
> +components are in place. We do our best to highlight the requirements here,
> +but this may not be an exhaustive list.
> +
> +
> +## enabling mitigations for x86 KVM guests
> +
> +For x86 guests there are 2 additional CPU flags associated with
> +Spectre/Meltdown mitigation
: **spec‑ctrl**, and **ibpb**. These flags
> +expose additional functionality made available through new microcode
> +updates for certain Intel/AMD processors that can be used to mitigate
> +various attack vectors related to Spectre. (Meltdown mitigation via KPTI
> +does not require additional CPU functionality or microcode, and does not
> +require an updated QEMU, only the related guest/host kernel patches).
> +
> +These CPU flags:
> +
> +* spec‑ctrl: exposes Indirect Branch Restricted Speculation (IBRS)
> +* ibpb: exposes Indirect Branch Prediction Barriers
> +
> +are both features requiring guest/host kernel updates, as well as
> +microcode updates for Intel and recent AMD processors. The status of
> +these kernel patches upstream is still in flux, but most supported
> +distros have some form of the patches that is sufficient to make use
> +of the features. The current status/availability of microcode updates
> +depends on your CPU architecture/model. Please check with your
> +vendor/distro to confirm these prerequisites are available/installed.
> +
> +Generally, for Intel CPUs with updated microcode, **spec‑ctrl** will
> +enable both IBRS and IBPB functionality. For AMD EPYC processors,
> +**ibpb** can be used to enable IBPB specifically, and is thought to
> +be sufficient by itself that particular architecture.

be sufficient by itself for that particular architecture

> +
> +These flags can be set in a similar manner as other CPU flags, i.e.:
> +
> +    qemu‑system‑x86_64 ‑cpu qemu64,+spec‑ctrl,... ...
> +    qemu‑system‑x86_64 ‑cpu IvyBridge,+spec‑ctrl,... ...
> +    qemu‑system‑x86_64 ‑cpu EPYC,+ibpb
> +    etc...

kind of a nit, but might as well be consistent here, as in:
qemu-system-x86_64 -cpu EPYC,+ibpb,... ...


Thanks for putting this together!

Bruce