linux-kernel - Re: [PATCH] KVM: x86: Disallow setting CPUID and/or feature MSRs if L2 is active

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aV7JM22lr8e7_oJ6@google.com>
Date: Wed, 7 Jan 2026 12:59:31 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Yosry Ahmed <yosry.ahmed@...ux.dev>
Cc: Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Kevin Cheng <chengkev@...gle.com>
Subject: Re: [PATCH] KVM: x86: Disallow setting CPUID and/or feature MSRs if
 L2 is active

On Wed, Jan 07, 2026, Yosry Ahmed wrote:
> On Wed, Jan 07, 2026 at 08:47:02PM +0000, Yosry Ahmed wrote:
> > On Tue, Dec 30, 2025 at 12:56:41PM -0800, Sean Christopherson wrote:
> > > Extend KVM's restriction on CPUID and feature MSR changes to disallow
> > > updates while L2 is active in addition to rejecting updates after the vCPU
> > > has run at least once.  Like post-run vCPU model updates, attempting to
> > > react to model changes while L2 is active is practically infeasible, e.g.
> > > KVM would need to do _something_ in response to impossible situations where
> > > userspace has a removed a feature that was consumed as parted of nested
> > > VM-Enter.
> > 
> > Another reason why I think this may be needed, but I am not sure:
> > 
> > If kvm_vcpu_after_set_cpuid() is executed while L2 is active,
> > KVM_REQ_RECALC_INTERCEPTS will cause
> > svm_recalc_intercepts()->svm_recalc_instruction_intercepts() in the
> > context of L2. While the svm_clr_intercept() and svm_set_intercept()
> > calls explicitly modify vmcb01, we set and clear
> > VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK in svm->vmcb->control.virt_ext. So
> > this will set/clear the bit in vmcb02.
> > 
> > I think this is a bug, because we could end up setting
> > VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK when we shouldn't (e.g. L1 doesn't set
> > in vmcb12, or the X86_FEATURE_V_VMSAVE_VMLOAD is not exposed to L1).
> > 
> > Actually as I am typing this, I believe a separate fix for this is
> > needed. We should be probably setting/clearing
> > VIRTUAL_VMLOAD_VMSAVE_ENABLE_MASK on svm->vmcb01.control.
> > 
> > Did I miss something?
> 
> If the analysis above is correct, then a separate fix is indeed required
> because we can end up in the same situation from
> kvm_vm_ioctl_set_msr_filter() -> KVM_REQ_RECALC_INTERCEPTS.

Ouch.  Yep, svm_recalc_instruction_intercepts() should always operate on vmcb01.