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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DDBC9C433EF for ; Fri, 24 Jun 2022 15:12:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0BF798E022E; Fri, 24 Jun 2022 11:12:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0702B8E020E; Fri, 24 Jun 2022 11:12:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E79648E022E; Fri, 24 Jun 2022 11:12:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D8A108E020E for ; Fri, 24 Jun 2022 11:12:33 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B2F0E34C05 for ; Fri, 24 Jun 2022 15:12:33 +0000 (UTC) X-FDA: 79613470986.03.5AC5D2E Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com [209.85.167.45]) by imf06.hostedemail.com (Postfix) with ESMTP id 636A018002E for ; Fri, 24 Jun 2022 15:12:33 +0000 (UTC) Received: by mail-lf1-f45.google.com with SMTP id c2so5092323lfk.0 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=DYEbmUoPRK/u92SevV6s4HYs6UrRgW4pejD36PyNsH5tOM47VkTTeleBJ/qzi84D8P ipWlA4raD/vJQQZUcKWGZWbJblISE763M2epek8xjBvCyjdX6DPUP8nsGajp9G8a+7sc ZVHkidwePEMzcQh8bE/P8hTAxIZ7lA1uo6wUM7Y7Eo7EZdW2TydndHNImfWFwsRizdaP h0Jttv3YovPEZaD8SdhbQkG6EHSfpfSLMq/UY0qjE8Vh21jVYYyAYsy/mO6ln2UTPteo opIApPdHev8gDrHbry/yZtGXv4EB7Oy1DciZvowx4+1Me8pbbwYSZnzmbGRNfyxOT/rM hF3w== X-Gm-Message-State: AJIora+IjwZgtOZfLUAIAPoL6S+o2oynb80PfjBNn6sduY9fKFd+a0g7 EWZO+4etazgjJizP/EKnDoyzKVO7L283myTI/sYqQg== X-Google-Smtp-Source: AGRyM1ux6fJI1UqfhbKtYI3380oq0Yc9WPcnS1B8UQFcR4k15s9NIrtzUEPIL6muaukL0Y7LrG0POm9dBMYr5wpMzHA= 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" ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mVTuWLuN; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of pgonda@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=pgonda@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656083553; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=x8Jy0OJ39PBOXthgIfAdqP1jgQfbb438h2GvJW/Mdq0=; b=k3FQ9l4vgaXy9hvky4Ki3QKDobbL1RhbxfwEKUTWST/1JPeZZ/Jwc5E+96chRIZeMx0Hwk PLRgMH2b5vJpJi9qthPWme+sTuKXfrCVUrtgRNdTKYVOkb+S8PGAE/z1PEsX7EAnfOnubP mE2z2IiZVactGafaunh1R15cIcM+774= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656083553; a=rsa-sha256; cv=none; b=5SuA79PRsPdHNEuFbRmjdMZtWkmLIR7GIUxF3+VqDOyG9aEIZgIuNgu6aOZxdEf+HbVqM+ ZAvaj60O/W/c+7FiIKYRmwWBf4cgZ1FXWuKglDPaxda3aiTKrATWskaFkURV4KFPAgPN2d NDkXAgfNs1k4UxMJ+DnYLp8Z65lAQMA= X-Stat-Signature: rs8z1pzpguzptrxcnkbyxf7idzopcfbi X-Rspamd-Queue-Id: 636A018002E X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=mVTuWLuN; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf06.hostedemail.com: domain of pgonda@google.com designates 209.85.167.45 as permitted sender) smtp.mailfrom=pgonda@google.com X-Rspamd-Server: rspam12 X-HE-Tag: 1656083553-19430 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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?