On 1/13/21 6:36 PM, Sean Christopherson wrote: > Zero out the array of VMCB pointers so that pre_sev_run() won't see > garbage when querying the array to detect when an SEV ASID is being > associated with a new VMCB. In practice, reading random values is all > but guaranteed to be benign as a false negative (which is extremely > unlikely on its own) can only happen on CPU0 on the first VMRUN and would > only cause KVM to skip the ASID flush. For anything bad to happen, a > previous instance of KVM would have to exit without flushing the ASID, > _and_ KVM would have to not flush the ASID at any time while building the > new SEV guest. > > Cc: Borislav Petkov <b...@suse.de> > Cc: Tom Lendacky <thomas.lenda...@amd.com> > Cc: Brijesh Singh <brijesh.si...@amd.com> > Fixes: 70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is > enabled") > Signed-off-by: Sean Christopherson <sea...@google.com> > --- > arch/x86/kvm/svm/svm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c > index 7ef171790d02..ccf52c5531fb 100644 > --- a/arch/x86/kvm/svm/svm.c > +++ b/arch/x86/kvm/svm/svm.c > @@ -573,7 +573,7 @@ static int svm_cpu_init(int cpu) > if (svm_sev_enabled()) { > sd->sev_vmcbs = kmalloc_array(max_sev_asid + 1, > sizeof(void *), > - GFP_KERNEL); > + GFP_KERNEL | __GFP_ZERO); > if (!sd->sev_vmcbs) > goto free_save_area; > }
Reviewed-by: Brijesh Singh <brijesh.si...@amd.com>