* Michael Roth (mdr...@linux.vnet.ibm.com) wrote: > Quoting Dr. David Alan Gilbert (2018-02-14 10:50:40) > > * 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. > > > > > <snip> > > > > + > > > + > > > +## 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. > > > + > > > +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... > > > + > > > +Additionally, for management stacks that lack support for setting > > > +specific CPU flags, a set of new CPU types have been added which > > > +enable the appropriate CPU flags automatically: > > > + > > > + qemu-system-x86_64 -cpu Nehalem-IBRS ... > > > + qemu-system-x86_64 -cpu Westmere-IBRS ... > > > + qemu-system-x86_64 -cpu SandyBridge-IBRS ... > > > + qemu-system-x86_64 -cpu IvyBridge-IBRS ... > > > + qemu-system-x86_64 -cpu Haswell-IBRS ... > > > + qemu-system-x86_64 -cpu Haswell-noTSX-IBRS ... > > > + qemu-system-x86_64 -cpu Broadwell-IBRS ... > > > + qemu-system-x86_64 -cpu Broadwell-noTSX-IBRS ... > > > + qemu-system-x86_64 -cpu Skylake-Client-IBRS ... > > > + qemu-system-x86_64 -cpu Skylake-Server-IBRS ... > > > + qemu-system-x86_64 -cpu EPYC-IBPB ... > > > + > > > +With these settings enabled, guests may still require additional > > > +configuration to enable IBRS/IBPB, which may vary somewhat from one > > > +distro to another. For RHEL guests, the following resource may be > > > +useful: > > > + > > > +* https://access.redhat.com/articles/3311301 > > > + > > > +WRT migration compatibility, **spec-ctrl**/**ibrs** (or the corresponding > > > +CPU type) should be set the same on both source/target to maintain > > > +compatibility. Thus, guests will need to be rebooted to make use of > > > +the new features. > > > > There is an unfortunate wrinkle with respect to CPU type compatibility > > on x86; the retpoline code is looking like it has to do special > > cases for Skylake and other recent CPUs (fluching the return buffer) and > > it does this on the basis of CPUid/model rather than flags; so from > > QEMUs point of view, the normal trick we do about giving guests a false > > earlier CPU name (e.g. -cpu IvyBridge) and expecting them to run across > > a wide range of more modern hardware may not be secure. > > Hmm, that's referring to this thread and Eduardo's concerns? > https://lkml.org/lkml/2018/1/20/162
Yes. > In the context of enabling IBRS in guests, wouldn't > Skylake host <-> non-Skylake host migration still be safe, assuming the > IBRS bits are properly enabled? Even with the patches proposed in that > thread? That's my understanding. > For the purposes of this document I was sort of staying away from > retpoline since AFAIK IBRS is still considered more complete and seems > to be more widely deployed. I think the retpoline stuff is catching up. > But perhaps we can add note to clarify and > maybe help users plan better for future developments of the sort. Maybe > something like the following? > > > Note that this document centers around Spectre mitigation via IBRS/IBPB > features. Alternative approaches to addressing Spectre exist in the form > of 'retpoline'-enabled kernels and are outside the scope of this > document. However, if you plan on utilizing such a kernel in place of IBRS, > either now or in the future, note that some proposed forms of the code > still rely on IBRS as a fallback for certain architectures like Skylake. > In such cases it may be necessary to ensure that guests running on Skylake > hosts utilize a matching -cpu Skylake* model with appropriate IBRS options > enabled, otherwise such fallbacks may be unavailable and leave the guest > vulnerable. For more background on this particular consideration you can > view the discussion here: > > https://lkml.org/lkml/2018/1/29/634 It's a bit weird to end up pointing to them to a lkml post; Paolo: Any ideas on anything better to say? Dave > > > > Dave > > > > <snip> > > > -- > > Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK > > > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
