Re: [PATCH v1 10/28] KVM: SVM: Use a static ASID per vCPU

[Yosry Ahmed]

> @@ -487,6 +482,21 @@ static inline void vmcb_set_gpat(struct vmcb *vmcb, u64 data)
>         vmcb_mark_dirty(vmcb, VMCB_NPT);
>  }
>
> +extern kvm_tlb_tag_t fallback_asid;
> +
> +static inline kvm_tlb_tag_t allocate_asid(struct kvm_vcpu *vcpu)
> +{
> +       if (is_sev_guest(vcpu))
> +               return sev_get_asid(vcpu->kvm);
> +       return kvm_alloc_tlb_tag() ?: fallback_asid;
> +}
> +
> +static inline void free_asid(struct kvm_vcpu *vcpu, kvm_tlb_tag_t asid)
> +{
> +       if (!is_sev_guest(vcpu) && asid != fallback_asid)
> +               kvm_free_tlb_tag(asid);
> +}
> +

>From internal Sashiko:
---
Can this trigger a kernel warning during SEV VM destruction?

In sev_migrate_from(), the source VM's active flag is cleared via
src->active = false. However, the source VM's vCPUs still retain their
SEV ASIDs.

When the source VM is subsequently destroyed, free_asid() is called. Since
is_sev_guest(vcpu) now returns false for the source VM, the SEV ASID is
passed to the standard allocator:

kvm_free_tlb_tag(asid)
        WARN_ON_ONCE(tag < tlb_tags.start)

Because SEV ASIDs are numerically lower than the normal tag pool start, this
will trigger the warning. On production systems with panic_on_warn, could an
unprivileged user exploit this by migrating and destroying an SEV VM?
---

This is similar-ish to the other issue in this patch, and more
annoying. The SEV ASID is only freed when the VM is freed, which I
assume only happens after all vCPUs are destroyed and free_asid() is
called. I am not sure how important it is to actually clear the SEV
active flag on the source of the migration, but I'd rather not try and
find out.

We can simply drop the WARN here and ignore attempts to free a
reserved ASID. Another option is clearing src_svm->asid in
sev_migration_from().