From 564539e45e386971f73d05d5a3d9f457ded5535b Mon Sep 17 00:00:00 2001 From: Philip Guenther Date: Tue, 28 May 2019 18:20:02 +0000 Subject: Correct the test for when the L1TF vulnerablity has been mitigated via either hardware update (RDCL_NO) or our being nested in a VM which is handling the flushing via the L1D_FLUSH MSR. ok mlarkin@ --- sys/arch/amd64/amd64/identcpu.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/sys/arch/amd64/amd64/identcpu.c b/sys/arch/amd64/amd64/identcpu.c index f1c5dba931e..11fa3323d5e 100644 --- a/sys/arch/amd64/amd64/identcpu.c +++ b/sys/arch/amd64/amd64/identcpu.c @@ -1,4 +1,4 @@ -/* $OpenBSD: identcpu.c,v 1.111 2019/05/17 19:07:15 guenther Exp $ */ +/* $OpenBSD: identcpu.c,v 1.112 2019/05/28 18:20:01 guenther Exp $ */ /* $NetBSD: identcpu.c,v 1.1 2003/04/26 18:39:28 fvdl Exp $ */ /* @@ -1019,6 +1019,8 @@ cpu_check_vmm_cap(struct cpu_info *ci) /* * Check "L1 flush on VM entry" (Intel L1TF vuln) semantics + * Full details can be found here: + * https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-l1-terminal-fault */ if (!strcmp(cpu_vendor, "GenuineIntel")) { if (ci->ci_feature_sefflags_edx & SEFF0EDX_L1DF) @@ -1028,12 +1030,15 @@ cpu_check_vmm_cap(struct cpu_info *ci) /* * Certain CPUs may have the vulnerability remedied in - * hardware, check for that and override the setting - * calculated above. + * hardware (RDCL_NO), or we may be nested in an VMM that + * is doing flushes (SKIP_L1DFL_VMENTRY) using the MSR. + * In either case no mitigation at all is necessary. */ if (ci->ci_feature_sefflags_edx & SEFF0EDX_ARCH_CAP) { msr = rdmsr(MSR_ARCH_CAPABILITIES); - if (msr & ARCH_CAPABILITIES_SKIP_L1DFL_VMENTRY) + if ((msr & ARCH_CAPABILITIES_RDCL_NO) || + ((msr & ARCH_CAPABILITIES_SKIP_L1DFL_VMENTRY) && + ci->ci_vmm_cap.vcc_vmx.vmx_has_l1_flush_msr)) ci->ci_vmm_cap.vcc_vmx.vmx_has_l1_flush_msr = VMX_SKIP_L1D_FLUSH; } -- cgit v1.2.3