"""
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.
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):
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 ?
https://<email address hidden> /msg626552. html
On the first patch of the set, Eduardo says:
""" Server- 4.1.1 ies=on" and "stepping=5".
The last patch in the series demonstrates how the new feature can
be used to update a CPU model: it adds a Cascadelake-
CPU model, including "arch-capabilit
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/microarch itectures/ cascade_ lake
we have:
"""
Hardware mitigations for:
CVE-2017-5715 - Spectre (Variant 2) /en.wikipedia. org/wiki/ Spectre_ (security_ vulnerability)
https:/
CVE-2017-5754 - Meltdown (Variant 3) /en.wikipedia. org/wiki/ Meltdown_ (security_ vulnerability)
https:/
CVE-2018-3640 - RSRE - Rogue System Register Read (Variant 3a) /en.wikipedia. org/wiki/ Spectre_ (security_ vulnerability) #V3a
https:/
CVE-2018- {3620,3646} - Foreshadow (L1 Terminal Fault) VMs,VMM,OS,SMM /en.wikipedia. org/wiki/ Foreshadow_ (security_ vulnerability)
https:/
*MDS* (Microarchitectural Data Sampling) attacks: /en.wikipedia. org/wiki/ Microarchitectu ral_Data_ Sampling
(MDS; MFBDS, RIDL, MSBDS, Fallout, MLPDS, MDSUM)
https:/
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:
""" Server- 4.1.1 CPU model instead of Server- 4.1.
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-
Cascadelake-
"""
Based on status on that discussion, unfinished and untested work, and Cosmic/ Disco, but, like we discussed, informing end
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/
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): l1dfl-vmentry
+rdctl-no
+ibrs-all
+rsba
+skip-
+ssb-no
+ssbd
+md-clear
just like you did in:
https:/ /wiki.ubuntu. com/SecurityTea m/KnowledgeBase /MDS
Will re-push merge request without stepping=6 for cascadelake.
Quick note:
https:/ /www.berrange. com/posts/ 2018/06/ 29/cpu- model-configura tion-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/