On 2/13/2018 at 5:11 PM, Michael Roth <mdr...@linux.vnet.ibm.com> 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 <ehabk...@redhat.com> > Cc: Paolo Bonzini <pbonz...@redhat.com> > Cc: Peter Maydell <peter.mayd...@linaro.org> > Cc: Suraj Jitindar Singh <sjitindarsi...@gmail.com> > Cc: David Gibson <da...@gibson.dropbear.id.au> > Cc: Christian Borntraeger <borntrae...@de.ibm.com> > Cc: Cornelia Huck <coh...@redhat.com> > Cc: Thomas Huth <th...@redhat.com> > Signed‑off‑by: Michael Roth <mdr...@linux.vnet.ibm.com> > ‑‑‑ > > 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
