https://www.mail-archive.com/qemu-devel@nongnu.org/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/ -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1828495 Title: [KVM][CLX] CPUID_7_0_EDX_ARCH_CAPABILITIES is not enabled in VM. Status in intel: New Status in linux package in Ubuntu: In Progress Status in qemu package in Ubuntu: In Progress Status in linux source package in Bionic: Confirmed Status in qemu source package in Bionic: Confirmed Status in linux source package in Cosmic: Confirmed Status in qemu source package in Cosmic: Confirmed Status in linux source package in Disco: Confirmed Status in qemu source package in Disco: Confirmed Status in linux source package in Eoan: In Progress Status in qemu source package in Eoan: In Progress Bug description: [Impact] * QEMU does not support IceLake and CascadeLake CPUs specific features. * Most important feature to be supported is: IA32_ARCH_CAPABILITIES MSR. * With IA32_ARCH_CAPABILITIES, QEMU is able to advertise HW mitigations: - Rogue Data Cache Load - Enhanced IBRS - RSB Alternate - L1D flush need on VMENTRY - speculative Store Bypass to guests, as described in document: Intel 336996-Speculative-Execution-Side-Channel-Mitigations.pdf [Test Case] * From Original Description: """ 1. Boot up guest using: -cpu Cascadelake-Server [root@clx-2s2 yexin]# qemu-system-x86_64 -accel kvm -drive if=virtio,id=hd,file=/home/x/x,format=qcow2 -m 4096 -smp 4 -cpu Cascadelake-Server -serial stdio char device redirected to /dev/pts/3 (label serial0) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.07H:ECX [bit 4] 2. To check CPU ID related to features[FEAT_7_0_EDX] ：CPUID_7_0_EDX_ARCH_CAPABILITIES Expected Result: Both host and guest's CPUID.07H EDX bit 29 should be 1. Actual Result: Host's cpuid: 0x00000007 0x00: eax=0x00000000 ebx=0xd39ffffb ecx=0x00000818 edx=0xbc000000 (EDX bit 29=1) Guest's cpuid : 0x00000007 0x00: eax=0x00000000 ebx=0xd19f0fb9 ecx=0x00000818 edx=0x84000000 (EDX bit 29=0) Commit:2bdb76c015df7125783d8394d6339d181cb5bc30 Target Kerned: 5.1 Target Release: 19.10 """ [Regression Potential] * Most changes are related to CPU type definitions and its supported features. They are all based in upstream changes but, for obvious reasons, backporting and/or cherry-picking those could bring issues. Biggest concern is breaking something that currently works. Right now, the parts being changed that could affect other CPU types would be related to a small refactoring of how the features are organized, and that would be seen right away when trying to start a new VM after the package is installed. * Other tests, related to the features being backported, are being done by our KVM regression tests, including migration combinations, to reduce chances that a regression is introduced. [Other Info] * N/A To manage notifications about this bug go to: https://bugs.launchpad.net/intel/+bug/1828495/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
