x86: Expose more MSR_ARCH_CAPS to hwdom

[PATCH] x86: Expose more MSR_ARCH_CAPS to hwdom

Posted by Jason Andryuk 1 year, 9 months ago

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(-)

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;
-- 
2.36.1

Re: [PATCH] x86: Expose more MSR_ARCH_CAPS to hwdom

Posted by Andrew Cooper 1 year, 9 months ago

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

Re: [PATCH] x86: Expose more MSR_ARCH_CAPS to hwdom

Posted by Jason Andryuk 1 year, 9 months ago

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