Comment 25 for bug 1828495

Revision history for this message
Rafael David Tinoco (rafaeldtinoco) wrote :

https://<email address hidden>/msg626552.html

On the first patch of the set, Eduardo says:

"""
The last patch in the series demonstrates how the new feature can
be used to update a CPU model: it adds a Cascadelake-Server-4.1.1
CPU model, including "arch-capabilities=on" and "stepping=5".
Unfortunately we can't enable arch-capabilities in the -4.1
version of Cascadelake-Server because it would break our existing
runnability guarantees.
"""

He likely discovered partial support for the mitigations on CPUs
with stepping=5 and wanted to implement arch_capabilities in order
to report those back to guests.

From:

https://en.wikichip.org/wiki/intel/microarchitectures/cascade_lake

we have:

"""
Hardware mitigations for:

CVE-2017-5715 - Spectre (Variant 2)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

CVE-2017-5754 - Meltdown (Variant 3)
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)

CVE-2018-3640 - RSRE - Rogue System Register Read (Variant 3a)
https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)#V3a

CVE-2018-{3620,3646} - Foreshadow (L1 Terminal Fault) VMs,VMM,OS,SMM
https://en.wikipedia.org/wiki/Foreshadow_(security_vulnerability)

*MDS* (Microarchitectural Data Sampling) attacks:
(MDS; MFBDS, RIDL, MSBDS, Fallout, MLPDS, MDSUM)
https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling

RIDL types:

1. (CVE-2018-12127) - MLPDS - Microarchitectural Load Port Data Sampling
2. (CVE-2018-12130) - MFBDS - Microarchitectural Fill Buffer Data Sampling
3. (CVE-2019-11091) - MDSUM - Microarchitectural Data Sampling Uncacheable Memory

https://mdsattacks.com/files/ridl.pdf

ZombieLoad type:

2. (CVE-2018-12130) - MFBDS - Microarchitectural Fill Buffer Data Sampling

Fallout type:

4. (CVE-2018-12126) - MSBDS - Microarchitectural StoreBuffer Data Sampling

https://mdsattacks.com/files/fallout.pdf

*** NOTE ***

- Steppings 6 and 7 are fully mitigated

- Stepping 5 is NOT PROTECTED against:

  a. MSBDS - (Faulout) Microarchitectural StoreBuffer Data Sampling
  b. MLPDS - (RIDL) Microarchitectural Load Port Data Sampling
  c. MDSUM - (RIDL) Microarchitectural Data Sampling Uncacheable Memory
"""

Commit 6/6 shows:

"""
The new feature will introduce a new host software requirement,
breaking our CPU model runnability promises. This means we can't
enable the new CPU model version by default in QEMU 4.1, because
management software isn't ready yet to resolve CPU model aliases.
This is why the feature is being enabled in a
Cascadelake-Server-4.1.1 CPU model instead of
Cascadelake-Server-4.1.
"""

Based on status on that discussion, unfinished and untested work, and
the fact that we're backporting things, and after our hangout, it is
clear the need to stay with stepping=5 in order to better maintain
qemu in Bionic/Cosmic/Disco, but, like we discussed, informing end
user about how to enable proper CPU flags to advertise HW mitigations
to the GUEST using specific cpu flags (QEMU and libvirt support):

+arch_capabilities (together with, or not):
    +rdctl-no
    +ibrs-all
    +rsba
    +skip-l1dfl-vmentry
    +ssb-no
+ssbd
+md-clear

just like you did in:

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/MDS

Will re-push merge request without stepping=6 for cascadelake.

Quick note:

https://www.berrange.com/posts/2018/06/29/cpu-model-configuration-for-qemu-kvm-on-x86-hosts/

Berrange has also documented CPU models and needed features
for the mitigations. I know this one is targetting Intel, but,
should we concern about the AMD mitigations for Bionic as well ?

Cheers o/