bhyve should expose MD_CLEAR capability

[pmooney_pfmooney.com]

Summary

With mitigations for the Intel MDS vulnerability in place, bhyve should expose the MD_CLEAR capability to guests when it is present.

Test Plan

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

[jhb]

I'm going to commit this in a bit, but I wanted to get @kib's opinion on whether there are other bits from other mitigations that we should be exposing to guests?

[kib]

We do not expose other bits from cpuid[7].edx because we do not pass MSR accesses to hardware, right ?

[jhb]

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)

[kib]

In D20296#437811, @jhb wrote:

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

Just handled.

#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.