From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-26.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT,USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14D89C433ED for ; Thu, 22 Apr 2021 02:11:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC4FB613A9 for ; Thu, 22 Apr 2021 02:11:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234093AbhDVCMI (ORCPT ); Wed, 21 Apr 2021 22:12:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230000AbhDVCMG (ORCPT ); Wed, 21 Apr 2021 22:12:06 -0400 Received: from mail-qt1-x84a.google.com (mail-qt1-x84a.google.com [IPv6:2607:f8b0:4864:20::84a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 39390C06138B for ; Wed, 21 Apr 2021 19:11:32 -0700 (PDT) Received: by mail-qt1-x84a.google.com with SMTP id g21-20020ac858150000b02901ba6163708bso4577548qtg.5 for ; Wed, 21 Apr 2021 19:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=reply-to:date:in-reply-to:message-id:mime-version:references :subject:from:to:cc; bh=es3BrEt/S0hj0elrM8cYzWujMT4DWRrvIdZx5ttB4mo=; b=rlXyrnFK0pqqsvHYF2rEC/rSf0+paRZxvod0CTuMJ5p3boxP32/+3hNxeIdLeJnXUv YYvxLUl/mqEKXMf+bs4laYvYIJnoUmTiFYMJvMEl8hZabkLViUmMl5lxaJtaBAb7q/m5 ali8h8VO0aBEYnZHRlZV2izoqU75j8CBPhre58Ww4rdteSJ8wc/3VBcBwVXcbD1FSoK+ iHEl5UEae68YZ7wT+hY5fBAg9z7ZnIBYY1MKC++wzvYpexgWV9pIJGAFtnJbdGbJagv4 6pbOkBKe7Fak61U8K7pKSemcA2JIx4eP9BtLuZ7aBakRNIS3epfHhUhdrvtzMmiz+ijW nqrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:date:in-reply-to:message-id :mime-version:references:subject:from:to:cc; bh=es3BrEt/S0hj0elrM8cYzWujMT4DWRrvIdZx5ttB4mo=; b=qEQa24hJaApbwzHemztkddI0ZU5SDXF3j5iHtq4bsx5N7IzjZgK/4NdQa+lo84vlar DlQmKOSH76IgwCCd74HNf2uF5NNzIzyJKBgTyWyIG6CLYIM0M+3lSu6IHiSGUmXpskzf GqQXZjAg6TRyGqJgEpU6w3YAQZJofdJpIQVEV+yRHjwiGYy5tqY3PTvqI8gtO1KOdAKC d9K6Kswi7oiTlmJcK9C90TRO98dgSy2uz0ZFkqrYlAJ5tPY5BErhJfKO4/mIilHplaLj cfdr8MQLYEo4oAgJanLR/In7ZJT2//xoak6hogHHo9/BnsSkn97aSVWftAiRlUKDIh90 MqDw== X-Gm-Message-State: AOAM532qdQP3zG66lveyeW//qsB72Fj8Tr+oE2Cipi9uZvZIlY+9+fzT cadaa19bEz05IZ1S8RC0LRM3cB/SMSE= X-Google-Smtp-Source: ABdhPJxiYCrJnCgureQBFXnyTKS0/Re5X2xbdqnEK6YpQ5OLkS7/63Tg/teL/Ifv9gMqblsCqfREmedXFyQ= X-Received: from seanjc798194.pdx.corp.google.com ([2620:15c:f:10:e012:374c:592:6194]) (user=seanjc job=sendgmr) by 2002:a0c:8521:: with SMTP id n30mr913189qva.53.1619057490787; Wed, 21 Apr 2021 19:11:30 -0700 (PDT) Reply-To: Sean Christopherson Date: Wed, 21 Apr 2021 19:11:11 -0700 In-Reply-To: <20210422021125.3417167-1-seanjc@google.com> Message-Id: <20210422021125.3417167-2-seanjc@google.com> Mime-Version: 1.0 References: <20210422021125.3417167-1-seanjc@google.com> X-Mailer: git-send-email 2.31.1.498.g6c1eba8ee3d-goog Subject: [PATCH v5 01/15] KVM: SVM: Zero out the VMCB array used to track SEV ASID association From: Sean Christopherson To: Paolo Bonzini , Dave Hansen , Andy Lutomirski , Peter Zijlstra Cc: Sean Christopherson , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Borislav Petkov , Tom Lendacky , Brijesh Singh Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 Reviewed-by: Tom Lendacky Reviewed-by: Brijesh Singh Fixes: 70cd94e60c73 ("KVM: SVM: VMRUN should use associated ASID when SEV is enabled") Signed-off-by: Sean Christopherson --- arch/x86/kvm/svm/svm.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c index cd8c333ed2dc..fed153314aef 100644 --- a/arch/x86/kvm/svm/svm.c +++ b/arch/x86/kvm/svm/svm.c @@ -563,9 +563,8 @@ static int svm_cpu_init(int cpu) clear_page(page_address(sd->save_area)); if (svm_sev_enabled()) { - sd->sev_vmcbs = kmalloc_array(max_sev_asid + 1, - sizeof(void *), - GFP_KERNEL); + sd->sev_vmcbs = kcalloc(max_sev_asid + 1, sizeof(void *), + GFP_KERNEL); if (!sd->sev_vmcbs) goto free_save_area; } -- 2.31.1.498.g6c1eba8ee3d-goog