With mitigations for the Intel MDS vulnerability in place, bhyve should expose the MD_CLEAR capability to guests when it is present.
jhb rgrimes kib
- Group Reviewers
- rS347964: Expose the MD_CLEAR capability used by Intel MDS mitigations to guests.
Running this patch on SmartOS bhyve, I booted Linux and Windows guests to confirm that the functionality was detected (once the guests were updated to include support for the mitigation).
I haven't personally made a conscious decision one way or another FWIW. If we should be exposing some of the MSRs and flag bits we can add that. I just wasn't sure which ones were relevant for guests (e.g. was L1TF only really an issue for hypervisors rather than something a guest or bare-metal kernel needs)
Below is the excerpt from specialregs.h with all the relevant bits:
#define CPUID_STDEXT3_MD_CLEAR 0x00000400
#define CPUID_STDEXT3_TSXFA 0x00002000
Not relevant until we start exposing PMCs to Guests.
#define CPUID_STDEXT3_IBPB 0x04000000 #define CPUID_STDEXT3_STIBP 0x08000000
Spectre v2 IBPB mitigations are relevant to Guests. Such attacks can be performed on guest kernel/guest user boundary.
#define CPUID_STDEXT3_L1D_FLUSH 0x10000000
L1TF is not relevant for FreeBSD OS because we never leave non-zero invalid PTEs installed in the paging structures. Would we only clear PG_V bit on pmap_remove(), L1D flush becomes mandatory to avoid random memory leak using L1TF.
#define CPUID_STDEXT3_ARCH_CAP 0x20000000 #define CPUID_STDEXT3_CORE_CAP 0x40000000
Relevant to Guests, is the pre-requisite to try to access ARCH_CAP MSR, see below.
#define CPUID_STDEXT3_SSBD 0x80000000
II am not sure that the control announced by this bit is useful for tweaks in Guests. It is global host control, IMO.
/* MSR IA32_ARCH_CAP(ABILITIES) bits */ #define IA32_ARCH_CAP_RDCL_NO 0x00000001 #define IA32_ARCH_CAP_IBRS_ALL 0x00000002 #define IA32_ARCH_CAP_RSBA 0x00000004 #define IA32_ARCH_CAP_SKIP_L1DFL_VMENTRY 0x00000008 #define IA32_ARCH_CAP_SSB_NO 0x00000010 #define IA32_ARCH_CAP_MDS_NO 0x00000020
All this is interesting to Guests which would avoid software mitigations if ARCH_CAP is exposed.