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 for Android: free password hash cracker in your pocket

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

Message-ID: <ttwq52yzpaymiygr3qgq3cmpghsakb4zdm6yf7qmp5dvvmylar@6ymzjweesi2x>
Date: Wed, 7 Jan 2026 20:49:08 +0000
From: Yosry Ahmed <yosry.ahmed@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
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 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.