Page MenuHomeFreeBSD

bhyve should expose MD_CLEAR capability
ClosedPublic

Authored by pmooney_pfmooney.com on May 17 2019, 7:11 PM.

Details

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

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

jhb added a subscriber: kib.May 18 2019, 8:43 PM
jhb added a comment.May 18 2019, 8:45 PM

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 accepted this revision.May 18 2019, 8:52 PM

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

This revision is now accepted and ready to land.May 18 2019, 8:52 PM
jhb added a comment.May 18 2019, 9:14 PM

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)

This revision was automatically updated to reflect the committed changes.
kib added a comment.May 18 2019, 9:36 PM
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.