Re: [PATCH v2 10/29] KVM: SVM: Use a static ASID per vCPU

[Yosry Ahmed <yosry@kernel.org>]

On Thu, Oct 08, 2026 at 12:30:26AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Critical] kvm: SEV VM intra-host migration leaves source vCPUs with the migrated SEV ASID, enabling cross-VM encryption context sharing
> --
> 
> commit f1bcd0115d8d6ff1f7f41fcb1c4ff86d4d68a34e
> Author: Yosry Ahmed <yosry@kernel.org>
> 
> KVM: SVM: Use a static ASID per vCPU
> 
> This commit switches KVM from dynamic ASID allocation to a static per-vCPU
> ASID scheme on SVM. It removes the generation-based wraparound tracking,
> instead tracking pending flushes in the VMCB and reusing the same ASID
> across physical CPUs.
> 
> > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> > index 0c3befd9bc850..8f27722bc4faf 100644
> > --- a/arch/x86/kvm/svm/svm.c
> > +++ b/arch/x86/kvm/svm/svm.c
> [ ... ]
> > @@ -3875,37 +3868,24 @@ static int pre_svm_run(struct kvm_vcpu *vcpu)
> >  {
> [ ... ]
> >  	if (is_sev_guest(vcpu))
> >  		return pre_sev_run(svm, vcpu->cpu);
> >  
> > -	/* FIXME: handle wraparound of asid_generation */
> > -	if (svm->current_vmcb->asid_generation != sd->asid_generation)
> > -		new_asid(svm, sd);
> > +	if (unlikely(svm->vmcb->control.asid == fallback_asid))
> > +		vmcb_set_flush_asid(svm->vmcb);
> >  
> >  	return 0;
> >  }
> 
> [Severity: Critical]
> With the removal of dynamic ASID reallocation in pre_svm_run(), can a source
> vCPU permanently retain its migrated SEV ASID after a
> KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM migration?
> 
> During a KVM_CAP_VM_MOVE_ENC_CONTEXT_FROM migration,
> sev_vm_move_enc_context_from() transfers the SEV ASID to the destination VM
> and marks the source VM as non-SEV. However, it intentionally skips the
> source vCPUs for vanilla SEV VMs:
> 
> arch/x86/kvm/svm/sev.c:sev_vm_move_enc_context_from() {
>         ...
> 		if (!dst->es_active)
> 			continue;
> 
> 		src_vcpu = kvm_get_vcpu(src_kvm, i);
> 		src_svm = to_svm(src_vcpu);
>         ...
> }
> 
> As a result, the source vCPUs retain the transferred SEV ASID (svm->asid)
> and the SVM_MISC_ENABLE_SEV bit in their VMCBs.
> 
> Previously, because the source VM was no longer considered an SEV guest,
> is_sev_guest() would return false, and the dynamic ASID allocation logic in
> pre_svm_run() would force the source vCPU to acquire a new, non-SEV ASID
> before running.
> 
> Now that the dynamic allocation logic is removed, the source vCPU will
> permanently retain the migrated SEV ASID.
> 
> If a malicious userspace hypervisor executes KVM_RUN on these zombie source
> vCPUs, KVM will treat the VM as non-SEV, allowing the hypervisor to bypass
> software protections and map its own nested page tables.

I am no SEV expert, but sev_vm_move_enc_context_from() calls
kvm_vm_dead() on the source VM, so all subsequent IOCTLs should fail,
including KVM_RUN, no?

> 
> Because the VMCB still has the SEV ASID and SEV=1, the hardware will decrypt
> the destination VM's memory using the destination's key. Does this break
> SEV confidentiality and memory isolation by allowing cross-VM encryption
> context sharing?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/20261008001425.2458927-1-yosry@kernel.org?part=10