KVM: SVM: Fix off-by-one indexing when nullifying last used SEV VMCB
authorSean Christopherson <seanjc@google.com>
Tue, 3 Aug 2021 16:27:46 +0000 (09:27 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 15 Aug 2021 12:00:24 +0000 (14:00 +0200)
commit9f105d2d4f6c60f92b0a0b5346a19b157d8d7e25
tree566eb34d09af4f3da285e5236bffc286d2a0e252
parent132a8267adabd645476b542b3b132c1b91988fe8
KVM: SVM: Fix off-by-one indexing when nullifying last used SEV VMCB

[ Upstream commit 179c6c27bf487273652efc99acd3ba512a23c137 ]

Use the raw ASID, not ASID-1, when nullifying the last used VMCB when
freeing an SEV ASID.  The consumer, pre_sev_run(), indexes the array by
the raw ASID, thus KVM could get a false negative when checking for a
different VMCB if KVM manages to reallocate the same ASID+VMCB combo for
a new VM.

Note, this cannot cause a functional issue _in the current code_, as
pre_sev_run() also checks which pCPU last did VMRUN for the vCPU, and
last_vmentry_cpu is initialized to -1 during vCPU creation, i.e. is
guaranteed to mismatch on the first VMRUN.  However, prior to commit
8a14fe4f0c54 ("kvm: x86: Move last_cpu into kvm_vcpu_arch as
last_vmentry_cpu"), SVM tracked pCPU on its own and zero-initialized the
last_cpu variable.  Thus it's theoretically possible that older versions
of KVM could miss a TLB flush if the first VMRUN is on pCPU0 and the ASID
and VMCB exactly match those of a prior VM.

Fixes: 70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is enabled")
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
arch/x86/kvm/svm/sev.c