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

[Michael Roth]

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

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?

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. 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

> 
> Dave
> 

<snip>

> --
> Dr. David Alan Gilbert / address@hidden / Manchester, UK
>