Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp515689iog; Fri, 24 Jun 2022 08:24:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1v4i5tXCP0/58o/ch+l3gp6wWwVjNCwKVjLyXWS0O0OGfMSFK4N/LJOn0C14IigRHBfuE7G X-Received: by 2002:a17:906:dc92:b0:725:be18:dc1b with SMTP id cs18-20020a170906dc9200b00725be18dc1bmr8313749ejc.530.1656084241027; Fri, 24 Jun 2022 08:24:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656084241; cv=none; d=google.com; s=arc-20160816; b=wm6gTj2UKTOpqKwL6p1P093pAvUSp3tfJFXd43maDOe4T4JxJIT9DqvnmLDf2CjixI Jexpx9Ae3Djyh6f6gMQOhyGwpb20tEufnPIQFAxD+fLFgSrD12e6gkctVBORkRmv5QYr LL/GvOysL5mWJAij0GwrpeaWR+tcnC2M93RmXKDQO65Dm27vsPnwk35v/c0URhEKhQ9F CG01vmr7BW7O/10A7aVJN70mCjwU2HR/8O9wWYVcXrd2SFjphMjUVPz6hKuivk2GmekR NI5rMDnvcZlKLMzr4IKp6oGlBPyCEeamrLK1LOPwnvuK/OttIt/eY9WZc6DZYWKTwXX0 IXWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=x8Jy0OJ39PBOXthgIfAdqP1jgQfbb438h2GvJW/Mdq0=; b=Xr3+/8Ye0h/aeADT6VzG9o9bCSBtEXtpAeLdF+NSbj1jKL6BAAtfq2otrUgTkNC6rt 61cwbrA4GFBEV77pXXwXOgo91I0JxTD1sz19rlPWSOjC4c0C75oi3lGlhU+XcugRfBRt cc0WhS65tzVIIQkID4Pp2T750tIWrJhXNXYR2SdIqXu1OE/OcK8FB/tK1C8zsX043a7S G+mJ7vihOLACxCUTdfRkP0gFhzEj7X4/DAaS/lFnFVDQ0RlqbJt3U993W7CRMR/HGvY8 Dxzjnsed+hDStsOOmYpOyJ9O87iLVS+BFuX26QeK06SfI4OaTMi9NFo/PSql6WWcbbbJ YmkA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=mVTuWLuN; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id gx20-20020a1709068a5400b0070fe457d158si1066612ejc.71.2022.06.24.08.23.25; Fri, 24 Jun 2022 08:24:01 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=mVTuWLuN; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232566AbiFXPMj (ORCPT + 99 others); Fri, 24 Jun 2022 11:12:39 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232504AbiFXPMf (ORCPT ); Fri, 24 Jun 2022 11:12:35 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A1EC4D9CD for ; Fri, 24 Jun 2022 08:12:33 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id z21so4940262lfb.12 for ; Fri, 24 Jun 2022 08:12:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x8Jy0OJ39PBOXthgIfAdqP1jgQfbb438h2GvJW/Mdq0=; b=mVTuWLuN8XZpFMJ+S+7U0qjJl+qK5dJblLURULdgRe/zT3wWoBwZfRqWcI9kIGhQix nJ0AlpkWAXgQzKGyiv+kR+rVuzVz+DEiOKI+39aGe1PTUDQ8PQmnF7lzUOTyeVqe+jYj /sPnpedyt4AqMb/Oe/lOmeQR9MXlebXyA5UNaCTZQAkhpYwhIjp+b0opRH/UNwzNPtdQ Kk22/0JzzDkTIXbMGifjZwkz6D6F0dqP5YXT6OK/4HiWJaQ2EEPlJAoKT7iFqZHu+CO3 yCdSI3Vrj02rJYLXVd24AKX1AmjoKBptyIgnOqn/2cJdm0bxgeklwSTdhUM5wS9vLoIB buLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x8Jy0OJ39PBOXthgIfAdqP1jgQfbb438h2GvJW/Mdq0=; b=4ZlAfJpMfacKvRZKd4NV83enoZ9sC4Wmc/Ek1efE9WJnxD8ph0FHnbKpfWxLDIYLBm cgYN3a+PydbfwwhcFox6kCw4yW0BIgT7xMxKAUJkY10dmxg1kOmxdU5ST9IwaxZfZvyv yQ+KUjVxlH8fFzfxBBDSZTY3vqW1CZdX/kCZo6ryZIIn643q87QE+uE7usbccq4KO9Wr fJBficxaMsGuKdsnX6JyzRPC/LFn9RVEQTNyRLKj9mu6/GsDVWFNJoHvW4z5CyyxCoWi C1rBaKst7eC4pEKP0hrruY4d5XYBjKkn0VLa0vdCWd5Q4NImbcERCnh4eez1Hs4XFgg/ oZcA== X-Gm-Message-State: AJIora9FgZ7hz+DCKtUjIioEVT57nLH+Zkr+BVeWq42q4mAtgaXrjIFl fVNtUQV0KTnNh0e3gpLd6uNoNlbPH3TFUgbplC0Emw== X-Received: by 2002:a05:6512:401a:b0:47f:6ea5:dace with SMTP id br26-20020a056512401a00b0047f6ea5dacemr9014219lfb.402.1656083551555; Fri, 24 Jun 2022 08:12:31 -0700 (PDT) MIME-Version: 1.0 References: <7845d453af6344d0b156493eb4555399aad78615.1655761627.git.ashish.kalra@amd.com> In-Reply-To: <7845d453af6344d0b156493eb4555399aad78615.1655761627.git.ashish.kalra@amd.com> From: Peter Gonda Date: Fri, 24 Jun 2022 09:12:20 -0600 Message-ID: Subject: Re: [PATCH Part2 v6 35/49] KVM: SVM: Remove the long-lived GHCB host map To: Ashish Kalra Cc: "the arch/x86 maintainers" , LKML , kvm list , linux-coco@lists.linux.dev, linux-mm@kvack.org, Linux Crypto Mailing List , Thomas Gleixner , Ingo Molnar , Joerg Roedel , "Lendacky, Thomas" , "H. Peter Anvin" , Ard Biesheuvel , Paolo Bonzini , Sean Christopherson , Vitaly Kuznetsov , Jim Mattson , Andy Lutomirski , Dave Hansen , Sergio Lopez , Peter Zijlstra , Srinivas Pandruvada , David Rientjes , Dov Murik , Tobin Feldman-Fitzthum , Borislav Petkov , Michael Roth , Vlastimil Babka , "Kirill A . Shutemov" , Andi Kleen , Tony Luck , Marc Orr , Sathyanarayanan Kuppuswamy , Alper Gun , "Dr. David Alan Gilbert" , jarkko@kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org On Mon, Jun 20, 2022 at 5:11 PM Ashish Kalra wrote: > > From: Brijesh Singh > > On VMGEXIT, sev_handle_vmgexit() creates a host mapping for the GHCB GPA, > and unmaps it just before VM-entry. This long-lived GHCB map is used by > the VMGEXIT handler through accessors such as ghcb_{set_get}_xxx(). > > A long-lived GHCB map can cause issue when SEV-SNP is enabled. When > SEV-SNP is enabled the mapped GPA needs to be protected against a page > state change. > > To eliminate the long-lived GHCB mapping, update the GHCB sync operations > to explicitly map the GHCB before access and unmap it after access is > complete. This requires that the setting of the GHCBs sw_exit_info_{1,2} > fields be done during sev_es_sync_to_ghcb(), so create two new fields in > the vcpu_svm struct to hold these values when required to be set outside > of the GHCB mapping. > > Signed-off-by: Brijesh Singh > --- > arch/x86/kvm/svm/sev.c | 131 ++++++++++++++++++++++++++--------------- > arch/x86/kvm/svm/svm.c | 12 ++-- > arch/x86/kvm/svm/svm.h | 24 +++++++- > 3 files changed, 111 insertions(+), 56 deletions(-) > > diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c > index 01ea257e17d6..c70f3f7e06a8 100644 > --- a/arch/x86/kvm/svm/sev.c > +++ b/arch/x86/kvm/svm/sev.c > @@ -2823,15 +2823,40 @@ void sev_free_vcpu(struct kvm_vcpu *vcpu) > kvfree(svm->sev_es.ghcb_sa); > } > > +static inline int svm_map_ghcb(struct vcpu_svm *svm, struct kvm_host_map *map) > +{ > + struct vmcb_control_area *control = &svm->vmcb->control; > + u64 gfn = gpa_to_gfn(control->ghcb_gpa); > + > + if (kvm_vcpu_map(&svm->vcpu, gfn, map)) { > + /* Unable to map GHCB from guest */ > + pr_err("error mapping GHCB GFN [%#llx] from guest\n", gfn); > + return -EFAULT; > + } > + > + return 0; > +} There is a perf cost to this suggestion but it might make accessing the GHCB safer for KVM. Have you thought about just using kvm_read_guest() or copy_from_user() to fully copy out the GCHB into a KVM owned buffer, then copying it back before the VMRUN. That way the KVM doesn't need to guard against page_state_changes on the GHCBs, that could be a perf improvement in a follow up. Since we cannot unmap GHCBs I don't think UPM will help here so we probably want to make these patches safe against malicious guests making GHCBs private. But maybe UPM does help?