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

[Dr. David Alan Gilbert]

* Michael Roth (address@hidden) wrote:
> Quoting Dr. David Alan Gilbert (2018-02-14 10:50:40)
> > * 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.
> > > 
> 
> <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 / address@hidden / Manchester, UK
> > 
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK