From: Sean Christopherson <seanjc@google.com>
To: Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
Aaron Lewis <aaronlewis@google.com>,
Yu Zhang <yu.c.zhang@linux.intel.com>
Subject: [PATCH v2 3/4] KVM: nVMX: Don't muck with allowed sec exec controls on CPUID changes
Date: Tue, 13 Dec 2022 06:23:05 +0000 [thread overview]
Message-ID: <20221213062306.667649-4-seanjc@google.com> (raw)
In-Reply-To: <20221213062306.667649-1-seanjc@google.com>
Don't modify the set of allowed secondary execution controls, i.e. the
virtual MSR_IA32_VMX_PROCBASED_CTLS2, in response to guest CPUID changes.
To avoid breaking old userspace that never sets the VMX MSRs, i.e. relies
on KVM to provide a consistent vCPU model, keep the existing behavior if
userspace has never written MSR_IA32_VMX_PROCBASED_CTLS2.
KVM should not modify the VMX capabilities presented to L1 based on CPUID
as doing so may discard explicit settings provided by userspace. E.g. if
userspace does KVM_SET_MSRS => KVM_SET_CPUID and disables a feature in
the VMX MSRs but not CPUID (to prevent exposing the feature to L2), then
stuffing the VMX MSRs during KVM_SET_CPUID will expose the feature to L2
against userspace's wishes.
Alternatively, KVM could add a quirk, but that's less than ideal as a VMM
that is affected by the bug would need to be updated in order to opt out
of the buggy behavior. The "has the MSR ever been written" logic handles
both the care where an enlightened userspace sets the MSR during setup,
and the case where userspace blindly migrates the MSR, as the migrated
value will already have been sanitized by the source KVM.
Reported-by: Yu Zhang <yu.c.zhang@linux.intel.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
---
arch/x86/kvm/vmx/capabilities.h | 1 +
arch/x86/kvm/vmx/nested.c | 3 +++
arch/x86/kvm/vmx/vmx.c | 7 +++++--
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/vmx/capabilities.h b/arch/x86/kvm/vmx/capabilities.h
index cd2ac9536c99..7b08d6006f52 100644
--- a/arch/x86/kvm/vmx/capabilities.h
+++ b/arch/x86/kvm/vmx/capabilities.h
@@ -51,6 +51,7 @@ struct nested_vmx_msrs {
u64 cr4_fixed1;
u64 vmcs_enum;
u64 vmfunc_controls;
+ bool secondary_set_by_userspace;
};
struct vmcs_config {
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index d131375f347a..0140893412b7 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -1271,6 +1271,9 @@ vmx_restore_control_msr(struct vcpu_vmx *vmx, u32 msr_index, u64 data)
if (!is_bitwise_subset(supported, data, GENMASK_ULL(63, 32)))
return -EINVAL;
+ if (msr_index == MSR_IA32_VMX_PROCBASED_CTLS2)
+ vmx->nested.msrs.secondary_set_by_userspace = true;
+
vmx_get_control_msr(&vmx->nested.msrs, msr_index, &lowp, &highp);
*lowp = data;
*highp = data >> 32;
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 13d3f5eb4c32..dd0247bc7193 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -4456,9 +4456,12 @@ vmx_adjust_secondary_exec_control(struct vcpu_vmx *vmx, u32 *exec_control,
/*
* Update the nested MSR settings so that a nested VMM can/can't set
- * controls for features that are/aren't exposed to the guest.
+ * controls for features that are/aren't exposed to the guest. Stuff
+ * the MSR if and only if userspace hasn't explicitly set the MSR, i.e.
+ * to avoid ABI breakage if userspace might be relying on KVM's flawed
+ * behavior to expose features to L1.
*/
- if (nested) {
+ if (nested && !vmx->nested.msrs.secondary_set_by_userspace) {
/*
* All features that got grandfathered into KVM's flawed CPUID-
* induced manipulation of VMX MSRs are unconditionally exposed
--
2.39.0.rc1.256.g54fd8350bd-goog
next prev parent reply other threads:[~2022-12-13 6:23 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-13 6:23 [PATCH v2 0/4] KVM: nVMX: Fix 2nd exec controls override goofs Sean Christopherson
2022-12-13 6:23 ` [PATCH v2 1/4] KVM: nVMX: Properly expose ENABLE_USR_WAIT_PAUSE control to L1 Sean Christopherson
2022-12-13 10:26 ` Yu Zhang
2022-12-13 18:08 ` Jim Mattson
2022-12-13 6:23 ` [PATCH v2 2/4] KVM: nVMX: Don't stuff secondary execution control if it's not supported Sean Christopherson
2022-12-13 6:23 ` Sean Christopherson [this message]
2022-12-23 17:30 ` [PATCH v2 3/4] KVM: nVMX: Don't muck with allowed sec exec controls on CPUID changes Paolo Bonzini
2023-01-04 14:31 ` Sean Christopherson
2023-01-04 14:42 ` Sean Christopherson
2022-12-13 6:23 ` [PATCH v2 4/4] KVM: selftests: Test KVM's handling of VMX's sec exec MSR on KVM_SET_CPUID Sean Christopherson
2022-12-14 3:00 ` [PATCH v2 0/4] KVM: nVMX: Fix 2nd exec controls override goofs Yu Zhang
2022-12-15 0:18 ` Sean Christopherson
2022-12-15 11:24 ` Yu Zhang
2022-12-15 18:33 ` Sean Christopherson
2022-12-16 9:59 ` Yu Zhang
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=20221213062306.667649-4-seanjc@google.com \
--to=seanjc@google.com \
--cc=aaronlewis@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yu.c.zhang@linux.intel.com \
/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