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

[sashiko-bot@kernel.org]

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.

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