From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
stable@vger.kernel.org,
Pawan Gupta <pawan.kumar.gupta@linux.intel.com>,
Borislav Petkov <bp@suse.de>,
Thomas Gleixner <tglx@linutronix.de>,
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Subject: [PATCH 4.14 19/20] KVM: x86/speculation: Disable Fill buffer clear within guests
Date: Tue, 14 Jun 2022 20:40:10 +0200 [thread overview]
Message-ID: <20220614183728.004188568@linuxfoundation.org> (raw)
In-Reply-To: <20220614183723.328825625@linuxfoundation.org>
From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
commit 027bbb884be006b05d9c577d6401686053aa789e upstream
The enumeration of MD_CLEAR in CPUID(EAX=7,ECX=0).EDX{bit 10} is not an
accurate indicator on all CPUs of whether the VERW instruction will
overwrite fill buffers. FB_CLEAR enumeration in
IA32_ARCH_CAPABILITIES{bit 17} covers the case of CPUs that are not
vulnerable to MDS/TAA, indicating that microcode does overwrite fill
buffers.
Guests running in VMM environments may not be aware of all the
capabilities/vulnerabilities of the host CPU. Specifically, a guest may
apply MDS/TAA mitigations when a virtual CPU is enumerated as vulnerable
to MDS/TAA even when the physical CPU is not. On CPUs that enumerate
FB_CLEAR_CTRL the VMM may set FB_CLEAR_DIS to skip overwriting of fill
buffers by the VERW instruction. This is done by setting FB_CLEAR_DIS
during VMENTER and resetting on VMEXIT. For guests that enumerate
FB_CLEAR (explicitly asking for fill buffer clear capability) the VMM
will not use FB_CLEAR_DIS.
Irrespective of guest state, host overwrites CPU buffers before VMENTER
to protect itself from an MMIO capable guest, as part of mitigation for
MMIO Stale Data vulnerabilities.
Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
[cascardo: arch/x86/kvm/vmx.c has been split and context adjustment at
vmx_vcpu_run]
[cascardo: moved functions so they are after struct vcpu_vmx definition]
[cascardo: fb_clear is disabled/enabled around __vmx_vcpu_run]
[cascardo: conflict context fixups]
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/x86/include/asm/msr-index.h | 6 +++
arch/x86/kvm/vmx.c | 74 ++++++++++++++++++++++++++++++++++++++-
arch/x86/kvm/x86.c | 4 ++
3 files changed, 83 insertions(+), 1 deletion(-)
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -115,6 +115,11 @@
* VERW clears CPU fill buffer
* even on MDS_NO CPUs.
*/
+#define ARCH_CAP_FB_CLEAR_CTRL BIT(18) /*
+ * MSR_IA32_MCU_OPT_CTRL[FB_CLEAR_DIS]
+ * bit available to control VERW
+ * behavior.
+ */
#define MSR_IA32_FLUSH_CMD 0x0000010b
#define L1D_FLUSH BIT(0) /*
@@ -132,6 +137,7 @@
/* SRBDS support */
#define MSR_IA32_MCU_OPT_CTRL 0x00000123
#define RNGDS_MITG_DIS BIT(0)
+#define FB_CLEAR_DIS BIT(3) /* CPU Fill buffer clear disable */
#define MSR_IA32_SYSENTER_CS 0x00000174
#define MSR_IA32_SYSENTER_ESP 0x00000175
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -214,6 +214,9 @@ static const struct {
#define L1D_CACHE_ORDER 4
static void *vmx_l1d_flush_pages;
+/* Control for disabling CPU Fill buffer clear */
+static bool __read_mostly vmx_fb_clear_ctrl_available;
+
static int vmx_setup_l1d_flush(enum vmx_l1d_flush_state l1tf)
{
struct page *page;
@@ -820,6 +823,8 @@ struct vcpu_vmx {
*/
u64 msr_ia32_feature_control;
u64 msr_ia32_feature_control_valid_bits;
+ u64 msr_ia32_mcu_opt_ctrl;
+ bool disable_fb_clear;
};
enum segment_cache_field {
@@ -1628,6 +1633,60 @@ static inline void __invept(unsigned lon
: : "a" (&operand), "c" (ext) : "cc", "memory");
}
+static void vmx_setup_fb_clear_ctrl(void)
+{
+ u64 msr;
+
+ if (boot_cpu_has(X86_FEATURE_ARCH_CAPABILITIES) &&
+ !boot_cpu_has_bug(X86_BUG_MDS) &&
+ !boot_cpu_has_bug(X86_BUG_TAA)) {
+ rdmsrl(MSR_IA32_ARCH_CAPABILITIES, msr);
+ if (msr & ARCH_CAP_FB_CLEAR_CTRL)
+ vmx_fb_clear_ctrl_available = true;
+ }
+}
+
+static __always_inline void vmx_disable_fb_clear(struct vcpu_vmx *vmx)
+{
+ u64 msr;
+
+ if (!vmx->disable_fb_clear)
+ return;
+
+ rdmsrl(MSR_IA32_MCU_OPT_CTRL, msr);
+ msr |= FB_CLEAR_DIS;
+ wrmsrl(MSR_IA32_MCU_OPT_CTRL, msr);
+ /* Cache the MSR value to avoid reading it later */
+ vmx->msr_ia32_mcu_opt_ctrl = msr;
+}
+
+static __always_inline void vmx_enable_fb_clear(struct vcpu_vmx *vmx)
+{
+ if (!vmx->disable_fb_clear)
+ return;
+
+ vmx->msr_ia32_mcu_opt_ctrl &= ~FB_CLEAR_DIS;
+ wrmsrl(MSR_IA32_MCU_OPT_CTRL, vmx->msr_ia32_mcu_opt_ctrl);
+}
+
+static void vmx_update_fb_clear_dis(struct kvm_vcpu *vcpu, struct vcpu_vmx *vmx)
+{
+ vmx->disable_fb_clear = vmx_fb_clear_ctrl_available;
+
+ /*
+ * If guest will not execute VERW, there is no need to set FB_CLEAR_DIS
+ * at VMEntry. Skip the MSR read/write when a guest has no use case to
+ * execute VERW.
+ */
+ if ((vcpu->arch.arch_capabilities & ARCH_CAP_FB_CLEAR) ||
+ ((vcpu->arch.arch_capabilities & ARCH_CAP_MDS_NO) &&
+ (vcpu->arch.arch_capabilities & ARCH_CAP_TAA_NO) &&
+ (vcpu->arch.arch_capabilities & ARCH_CAP_PSDP_NO) &&
+ (vcpu->arch.arch_capabilities & ARCH_CAP_FBSDP_NO) &&
+ (vcpu->arch.arch_capabilities & ARCH_CAP_SBDR_SSDP_NO)))
+ vmx->disable_fb_clear = false;
+}
+
static struct shared_msr_entry *find_msr_entry(struct vcpu_vmx *vmx, u32 msr)
{
int i;
@@ -3700,9 +3759,13 @@ static int vmx_set_msr(struct kvm_vcpu *
}
break;
}
- ret = kvm_set_msr_common(vcpu, msr_info);
+ ret = kvm_set_msr_common(vcpu, msr_info);
}
+ /* FB_CLEAR may have changed, also update the FB_CLEAR_DIS behavior */
+ if (msr_index == MSR_IA32_ARCH_CAPABILITIES)
+ vmx_update_fb_clear_dis(vcpu, vmx);
+
return ret;
}
@@ -6008,6 +6071,8 @@ static void vmx_vcpu_reset(struct kvm_vc
update_exception_bitmap(vcpu);
vpid_sync_context(vmx->vpid);
+
+ vmx_update_fb_clear_dis(vcpu, vmx);
}
/*
@@ -9783,6 +9848,8 @@ static void __noclone vmx_vcpu_run(struc
kvm_arch_has_assigned_device(vcpu->kvm))
mds_clear_cpu_buffers();
+ vmx_disable_fb_clear(vmx);
+
asm(
/* Store host registers */
"push %%" _ASM_DX "; push %%" _ASM_BP ";"
@@ -9900,6 +9967,8 @@ static void __noclone vmx_vcpu_run(struc
#endif
);
+ vmx_enable_fb_clear(vmx);
+
/*
* We do not use IBRS in the kernel. If this vCPU has used the
* SPEC_CTRL MSR it may have left it on; save the value and
@@ -12924,8 +12993,11 @@ static int __init vmx_init(void)
}
}
+ vmx_setup_fb_clear_ctrl();
+
for_each_possible_cpu(cpu) {
INIT_LIST_HEAD(&per_cpu(loaded_vmcss_on_cpu, cpu));
+
INIT_LIST_HEAD(&per_cpu(blocked_vcpu_on_cpu, cpu));
spin_lock_init(&per_cpu(blocked_vcpu_on_cpu_lock, cpu));
}
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1127,6 +1127,10 @@ u64 kvm_get_arch_capabilities(void)
/* KVM does not emulate MSR_IA32_TSX_CTRL. */
data &= ~ARCH_CAP_TSX_CTRL_MSR;
+
+ /* Guests don't need to know "Fill buffer clear control" exists */
+ data &= ~ARCH_CAP_FB_CLEAR_CTRL;
+
return data;
}
next prev parent reply other threads:[~2022-06-14 18:45 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-14 18:39 [PATCH 4.14 00/20] 4.14.284-rc1 review Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 01/20] x86/cpu: Add Elkhart Lake to Intel family Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 02/20] cpu/speculation: Add prototype for cpu_show_srbds() Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 03/20] x86/cpu: Add Jasper Lake to Intel family Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 04/20] x86/cpu: Add Cannonlake " Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 05/20] x86/CPU: Add Icelake model number Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 06/20] x86/CPU: Add more Icelake model numbers Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 07/20] x86/cpu: Add Comet Lake to the Intel CPU models header Greg Kroah-Hartman
2022-06-14 18:39 ` [PATCH 4.14 08/20] x86/cpu: Add Lakefield, Alder Lake and Rocket Lake models to the to Intel CPU family Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 09/20] x86/cpu: Add another Alder Lake CPU to the Intel family Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 10/20] Documentation: Add documentation for Processor MMIO Stale Data Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 11/20] x86/speculation/mmio: Enumerate Processor MMIO Stale Data bug Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 12/20] x86/speculation: Add a common function for MD_CLEAR mitigation update Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 13/20] x86/speculation/mmio: Add mitigation for Processor MMIO Stale Data Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 14/20] x86/bugs: Group MDS, TAA & Processor MMIO Stale Data mitigations Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 15/20] x86/speculation/mmio: Enable CPU Fill buffer clearing on idle Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 16/20] x86/speculation/mmio: Add sysfs reporting for Processor MMIO Stale Data Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 17/20] x86/speculation/srbds: Update SRBDS mitigation selection Greg Kroah-Hartman
2022-06-14 18:40 ` [PATCH 4.14 18/20] x86/speculation/mmio: Reuse SRBDS mitigation for SBDS Greg Kroah-Hartman
2022-06-14 18:40 ` Greg Kroah-Hartman [this message]
2022-06-14 18:40 ` [PATCH 4.14 20/20] x86/speculation/mmio: Print SMT warning Greg Kroah-Hartman
2022-06-15 17:58 ` [PATCH 4.14 00/20] 4.14.284-rc1 review Naresh Kamboju
2022-06-15 22:01 ` Guenter Roeck
2022-06-16 8:28 ` Jon Hunter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220614183728.004188568@linuxfoundation.org \
--to=gregkh@linuxfoundation.org \
--cc=bp@suse.de \
--cc=cascardo@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox