diff mbox series

[v2,3/4] KVM: nVMX: Don't muck with allowed sec exec controls on CPUID changes

Message ID 20221213062306.667649-4-seanjc@google.com
State New
Headers
Series KVM: nVMX: Fix 2nd exec controls override goofs |

Commit Message

Sean Christopherson Dec. 13, 2022, 6:23 a.m. UTC 
  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(-)

Comments

Paolo Bonzini Dec. 23, 2022, 5:30 p.m. UTC | #1 
On 12/13/22 07:23, Sean Christopherson wrote:
> 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.

The commit message doesn't explain *why* KVM_SET_CPUID would be done 
before KVM_SET_MSRS.  The presence of certain MSRs or bits within is 
signaled by CPUID bits, and even though KVM is more lenient on 
host-initiated MSR writes it still verifies in general that the bits are 
valid.

For now I applied patch 1 and (with a reworded comment) patch 2.  I'm 
not opposed to the rest, but I would like to better understand the 
reason for them.  (If it has been reported to the mailing list, please 
add a "Link" trailer too).

Paolo
Sean Christopherson Jan. 4, 2023, 2:31 p.m. UTC | #2 
On Fri, Dec 23, 2022, Paolo Bonzini wrote:
> On 12/13/22 07:23, Sean Christopherson wrote:
> > 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.
> 
> The commit message doesn't explain *why* KVM_SET_CPUID would be done before
> KVM_SET_MSRS.

I assume you mean why KVM_SET_MSRS would be done before KVM_SET_CPUID2?

This patch is mostly paranoia, AFAIK there is no userspace that is negatively
affected by KVM's manipulations.  The only case I can think of is if userspace
wanted to emulate dynamic CPUID updates, e.g. set an MSR filter to intercept writes
to MISC_ENABLES to update MONITOR/MWAIT support, but that behavior isn't allowed
since commit feb627e8d6f6 ("KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN").

There are scenarios where userspace might do KVM_SET_MSRS before KVM_SET_CPUID,
e.g. QEMU's reuse of a vCPU for CPU hotplug, but in those cases I would expect
userspace to follow up with another KVM_SET_MSRS.
Sean Christopherson Jan. 4, 2023, 2:42 p.m. UTC | #3 
On Wed, Jan 04, 2023, Sean Christopherson wrote:
> On Fri, Dec 23, 2022, Paolo Bonzini wrote:
> > On 12/13/22 07:23, Sean Christopherson wrote:
> > > 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.
> > 
> > The commit message doesn't explain *why* KVM_SET_CPUID would be done before
> > KVM_SET_MSRS.
> 
> I assume you mean why KVM_SET_MSRS would be done before KVM_SET_CPUID2?
> 
> This patch is mostly paranoia, AFAIK there is no userspace that is negatively
> affected by KVM's manipulations.  The only case I can think of is if userspace
> wanted to emulate dynamic CPUID updates, e.g. set an MSR filter to intercept writes
> to MISC_ENABLES to update MONITOR/MWAIT support, but that behavior isn't allowed
> since commit feb627e8d6f6 ("KVM: x86: Forbid KVM_SET_CPUID{,2} after KVM_RUN").
> 
> There are scenarios where userspace might do KVM_SET_MSRS before KVM_SET_CPUID,
> e.g. QEMU's reuse of a vCPU for CPU hotplug, but in those cases I would expect
> userspace to follow up with another KVM_SET_MSRS.

An argument for taking this patch is that it might be necessary to disallow
KVM_SET_MSRS after KVM_RUN[*].  If KVM manipulates VMX MSRs during KVM_SET_CPUID2,
reusing a vCPU with sequence:

  SET_CPUID2 => SET_MSRS => RUN => unplug => hotplug => SET_CPUID2 => SET_MSRS

sequence will cause the second SET_MSRS to fail due to userspace "changing" the
MSR value.

[*] https://lore.kernel.org/all/20220805172945.35412-4-seanjc@google.com
diff mbox series

Patch

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