| Message ID | 20220719200815.69884-1-jandryuk@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: Expose more MSR_ARCH_CAPS to hwdom | expand |
On 19/07/2022 21:08, Jason Andryuk wrote: > commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started > exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since > been defined, but they haven't been exposed. Update the list to allow > them through. > > As one example, this allows a linux Dom0 to know that it has the > appropriate microcode via FB_CLEAR. Notably, and with the updated > microcode, this changes dom0's > /sys/devices/system/cpu/vulnerabilities/mmio_stale_data changes from: > "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state > unknown" > to: > "Mitigation: Clear CPU buffers; SMT Host state unknown" > > This ecposes the MMIO Stale Data and Intel Branch History Injection > (BHI) controls as well as the page size change MCE issue bit. > > Fixes: commit 2ebe8fe9b7e0 ("x86/spec-ctrl: Enumeration for MMIO Stale Data controls") > Fixes: commit cea9ae062295 ("x86/spec-ctrl: Enumeration for new Intel BHI controls") > Fixes: commit 59e89cdabc71 ("x86/vtx: Disable executable EPT superpages to work around CVE-2018-12207") > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > --- > This is the broader replacement for "x86: Add MMIO Stale Data arch_caps > to hardware domain". > > It wasn't discussed previously, but ARCH_CAPS_IF_PSCHANGE_MC_NO is added > as well. I deliberately excluded IF_PSCHANGE_MC_NO because it wasn't relevant. But I suppose Linux is looking for it anyway? IF_PSCHANGE_MC_NO is the mouthful meaning "the frontend doesn't have a strop when it takes an assist finds that the iTLB mapping has changed". It's only interesting to hypervisors looking after an EPT guest, which means that it's only interesting to expose to HAP guests with nested virt. Except we disable mitigations for nested virt because there's a bug in the nHAP code which I didn't have time to figure out, and none of this is remotely security supported to start with. In principle, TAA_NO's visibility should be dependent on the visibility of RTM, but given this is all a pile of hacks anyway, I'm not sure how much I care at this point. ~Andrew
On Tue, Jul 19, 2022 at 4:29 PM Andrew Cooper <Andrew.Cooper3@citrix.com> wrote: > > On 19/07/2022 21:08, Jason Andryuk wrote: > > commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started > > exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since > > been defined, but they haven't been exposed. Update the list to allow > > them through. > > > > As one example, this allows a linux Dom0 to know that it has the > > appropriate microcode via FB_CLEAR. Notably, and with the updated > > microcode, this changes dom0's > > /sys/devices/system/cpu/vulnerabilities/mmio_stale_data changes from: > > "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state > > unknown" > > to: > > "Mitigation: Clear CPU buffers; SMT Host state unknown" > > > > This ecposes the MMIO Stale Data and Intel Branch History Injection > > (BHI) controls as well as the page size change MCE issue bit. > > > > Fixes: commit 2ebe8fe9b7e0 ("x86/spec-ctrl: Enumeration for MMIO Stale Data controls") > > Fixes: commit cea9ae062295 ("x86/spec-ctrl: Enumeration for new Intel BHI controls") > > Fixes: commit 59e89cdabc71 ("x86/vtx: Disable executable EPT superpages to work around CVE-2018-12207") > > > > Signed-off-by: Jason Andryuk <jandryuk@gmail.com> > > --- > > This is the broader replacement for "x86: Add MMIO Stale Data arch_caps > > to hardware domain". > > > > It wasn't discussed previously, but ARCH_CAPS_IF_PSCHANGE_MC_NO is added > > as well. > > I deliberately excluded IF_PSCHANGE_MC_NO because it wasn't relevant. > But I suppose Linux is looking for it anyway? Yeah, it looks like Linux checks that bit to determine if it is affected by what it calls "itlb_multihit". That's just from reading the code - I don't seem to have hardware that actually sets that bit though. > IF_PSCHANGE_MC_NO is the mouthful meaning "the frontend doesn't have a > strop when it takes an assist finds that the iTLB mapping has changed". > It's only interesting to hypervisors looking after an EPT guest, which > means that it's only interesting to expose to HAP guests with nested > virt. Except we disable mitigations for nested virt because there's a > bug in the nHAP code which I didn't have time to figure out, and none of > this is remotely security supported to start with. I can change this however you like. Basically my reasoning to include it was that since the "_NO" bits say the hardware is not affected by something, it's okay to pass it through. > In principle, TAA_NO's visibility should be dependent on the visibility > of RTM, but given this is all a pile of hacks anyway, I'm not sure how > much I care at this point. :/ Regards, Jason
diff --git a/xen/arch/x86/msr.c b/xen/arch/x86/msr.c index 6206529162..170f041793 100644 --- a/xen/arch/x86/msr.c +++ b/xen/arch/x86/msr.c @@ -72,7 +72,9 @@ static void __init calculate_host_policy(void) mp->arch_caps.raw &= (ARCH_CAPS_RDCL_NO | ARCH_CAPS_IBRS_ALL | ARCH_CAPS_RSBA | ARCH_CAPS_SKIP_L1DFL | ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | - ARCH_CAPS_IF_PSCHANGE_MC_NO | ARCH_CAPS_TSX_CTRL | ARCH_CAPS_TAA_NO); + ARCH_CAPS_IF_PSCHANGE_MC_NO | ARCH_CAPS_TSX_CTRL | ARCH_CAPS_TAA_NO | + ARCH_CAPS_SBDR_SSDP_NO | ARCH_CAPS_FBSDP_NO | ARCH_CAPS_PSDP_NO | + ARCH_CAPS_FB_CLEAR | ARCH_CAPS_RRSBA | ARCH_CAPS_BHI_NO); } static void __init calculate_pv_max_policy(void) @@ -161,7 +163,10 @@ int init_domain_msr_policy(struct domain *d) mp->arch_caps.raw = val & (ARCH_CAPS_RDCL_NO | ARCH_CAPS_IBRS_ALL | ARCH_CAPS_RSBA | - ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | ARCH_CAPS_TAA_NO); + ARCH_CAPS_SSB_NO | ARCH_CAPS_MDS_NO | ARCH_CAPS_IF_PSCHANGE_MC_NO | + ARCH_CAPS_TAA_NO | ARCH_CAPS_SBDR_SSDP_NO | ARCH_CAPS_FBSDP_NO | + ARCH_CAPS_PSDP_NO | ARCH_CAPS_FB_CLEAR | ARCH_CAPS_RRSBA | + ARCH_CAPS_BHI_NO); } d->arch.msr = mp;
commit e46474278a0e ("x86/intel: Expose MSR_ARCH_CAPS to dom0") started exposing MSR_ARCH_CAPS to dom0. More bits in MSR_ARCH_CAPS have since been defined, but they haven't been exposed. Update the list to allow them through. As one example, this allows a linux Dom0 to know that it has the appropriate microcode via FB_CLEAR. Notably, and with the updated microcode, this changes dom0's /sys/devices/system/cpu/vulnerabilities/mmio_stale_data changes from: "Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown" to: "Mitigation: Clear CPU buffers; SMT Host state unknown" This ecposes the MMIO Stale Data and Intel Branch History Injection (BHI) controls as well as the page size change MCE issue bit. Fixes: commit 2ebe8fe9b7e0 ("x86/spec-ctrl: Enumeration for MMIO Stale Data controls") Fixes: commit cea9ae062295 ("x86/spec-ctrl: Enumeration for new Intel BHI controls") Fixes: commit 59e89cdabc71 ("x86/vtx: Disable executable EPT superpages to work around CVE-2018-12207") Signed-off-by: Jason Andryuk <jandryuk@gmail.com> --- This is the broader replacement for "x86: Add MMIO Stale Data arch_caps to hardware domain". It wasn't discussed previously, but ARCH_CAPS_IF_PSCHANGE_MC_NO is added as well. This patch can't be directly backported because cea9ae062295 was not backported. xen/arch/x86/msr.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)