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

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Tue, Jul 19, 2022 at 4:29 PM Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx> 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@xxxxxxxxx>
> > ---
> > 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