Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp818624ybl; Thu, 22 Aug 2019 05:28:47 -0700 (PDT) X-Google-Smtp-Source: APXvYqyHnTKHtYFArC2/1uJEhPMYztw0R3roJ+tcFKCq2u4le5qHei3Ps58WSDBTmibr2nCmdDcD X-Received: by 2002:a17:90a:1d0:: with SMTP id 16mr5126355pjd.98.1566476927733; Thu, 22 Aug 2019 05:28:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1566476927; cv=none; d=google.com; s=arc-20160816; b=DHkXYY9SuBW7RVPkng8YZdzigIu3NBkbbWZ8WKfYbAIR8ngezsZyGVZXEa43myZr/R fMOcdEK4Ft4yYbF6U1DM3dNrs5+zUxlgqEwI7Owqnzl6i9GfMH5/GI7Cf6B8pCZKJFYF rz+adw7qq/i3GyPcD5Z7RuaIwategC414YCoPkVTaDS4whxk1ZZdsTGX9NbPXxT1D+K0 AMisKJfbyK5I1aEQ2ed1Aaq18adwxd/S246+fkcE5RsmHVVik4PIUhoezUEl/UTyty7V xU+wH4reBbbPiRe8E7K8iJ9qFa5/2n34wxHVNSmojviCxbX0eiyobl2wJ/lmE/g+AiFr FzWw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=t2X0XkvfoLL+I3pIdB/7sVhDmQXNcrmkgLJelKXpTYI=; b=gyeiMksAvEk3gevpdDvNf5wamW4mYuW8OH/Xw+/JGMORkDu6xQ4K0nX+vf1EtHvi2T pCPRM9ZqQEeusI0TFk1VegxyNRZrbdDbs+khSBGenOxhpxhGdCshVeRmSnP/O9X29Sb4 xqJrG6Z9d8oJvpEi3VqDDiq2Snq2WZ4bb5CnEFZaiVlmF8waGgx/G3R+fi7uSg3Xq1wU yLKy6Th+4RyD9xqNQclGeadJiW235idW13Dp5lO6vSPguwaxsTsm6xWpg2GMgH0NJt2n 6JsTKhIlZRMnZZN4L6Esf/MM7UpZcZyABJyF5mql6rxhbUdygEasbio9mLfQIapSKccR qVDw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r23si18483438pfg.124.2019.08.22.05.28.32; Thu, 22 Aug 2019 05:28:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732968AbfHVKIZ (ORCPT + 99 others); Thu, 22 Aug 2019 06:08:25 -0400 Received: from mx2.suse.de ([195.135.220.15]:53134 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1732938AbfHVKIZ (ORCPT ); Thu, 22 Aug 2019 06:08:25 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 9F080AC64; Thu, 22 Aug 2019 10:08:23 +0000 (UTC) Date: Thu, 22 Aug 2019 12:08:18 +0200 From: Borislav Petkov To: "Singh, Brijesh" Cc: "kvm@vger.kernel.org" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Paolo Bonzini , Radim =?utf-8?B?S3LEjW3DocWZ?= , Joerg Roedel , "Lendacky, Thomas" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH v3 01/11] KVM: SVM: Add KVM_SEV SEND_START command Message-ID: <20190822100818.GB11845@zn.tnic> References: <20190710201244.25195-1-brijesh.singh@amd.com> <20190710201244.25195-2-brijesh.singh@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190710201244.25195-2-brijesh.singh@amd.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 10, 2019 at 08:13:00PM +0000, Singh, Brijesh wrote: > The command is used to create an outgoing SEV guest encryption context. > > Cc: Thomas Gleixner > Cc: Ingo Molnar > Cc: "H. Peter Anvin" > Cc: Paolo Bonzini > Cc: "Radim Krčmář" > Cc: Joerg Roedel > Cc: Borislav Petkov > Cc: Tom Lendacky > Cc: x86@kernel.org > Cc: kvm@vger.kernel.org > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Brijesh Singh > --- > .../virtual/kvm/amd-memory-encryption.rst | 27 +++++ > arch/x86/kvm/svm.c | 105 ++++++++++++++++++ > include/uapi/linux/kvm.h | 12 ++ > 3 files changed, 144 insertions(+) > > diff --git a/Documentation/virtual/kvm/amd-memory-encryption.rst b/Documentation/virtual/kvm/amd-memory-encryption.rst > index d18c97b4e140..0e9e1e9f9687 100644 > --- a/Documentation/virtual/kvm/amd-memory-encryption.rst > +++ b/Documentation/virtual/kvm/amd-memory-encryption.rst Do a s/virtual/virt/g for the next revision because this path got changed recently: 2f5947dfcaec ("Documentation: move Documentation/virtual to Documentation/virt") > @@ -238,6 +238,33 @@ Returns: 0 on success, -negative on error > __u32 trans_len; > }; > > +10. KVM_SEV_SEND_START > +---------------------- > + > +The KVM_SEV_SEND_START command can be used by the hypervisor to create an > +outgoing guest encryption context. > + > +Parameters (in): struct kvm_sev_send_start > + > +Returns: 0 on success, -negative on error > + > +:: > + struct kvm_sev_send_start { > + __u32 policy; /* guest policy */ > + > + __u64 pdh_cert_uaddr; /* platform Diffie-Hellman certificate */ > + __u32 pdh_cert_len; > + > + __u64 plat_cert_uaddr; /* platform certificate chain */ > + __u32 plat_cert_len; > + > + __u64 amd_cert_uaddr; /* AMD certificate */ > + __u32 amd_cert_len; > + > + __u64 session_uaddr; /* Guest session information */ > + __u32 session_len; > + }; SEV API doc has "CERT" for PDH members but "CERTS" for the others. Judging by the description, you should do the same here too. Just so that there's no discrepancy from the docs. > + > References > ========== > > diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c > index 48c865a4e5dd..0b0937f53520 100644 > --- a/arch/x86/kvm/svm.c > +++ b/arch/x86/kvm/svm.c > @@ -6957,6 +6957,108 @@ static int sev_launch_secret(struct kvm *kvm, struct kvm_sev_cmd *argp) > return ret; > } > > +static int sev_send_start(struct kvm *kvm, struct kvm_sev_cmd *argp) > +{ > + struct kvm_sev_info *sev = &to_kvm_svm(kvm)->sev_info; > + void *amd_cert = NULL, *session_data = NULL; > + void *pdh_cert = NULL, *plat_cert = NULL; > + struct sev_data_send_start *data = NULL; Why are you initializing those to NULL? Also, SEV API text on SEND_START talks about a bunch of requirements in section "6.8.1 Actions" like "The platform must be in the PSTATE.WORKING state. The guest must be in the GSTATE.RUNNING state. GCTX.POLICY.NOSEND must be zero. Otherwise, an error is returned. ..." Where are we checking/verifying those? > + struct kvm_sev_send_start params; > + int ret; > + > + if (!sev_guest(kvm)) > + return -ENOTTY; > + > + if (copy_from_user(¶ms, (void __user *)(uintptr_t)argp->data, > + sizeof(struct kvm_sev_send_start))) > + return -EFAULT; > + > + data = kzalloc(sizeof(*data), GFP_KERNEL); > + if (!data) > + return -ENOMEM; Move that allocation... > + > + /* userspace wants to query the session length */ > + if (!params.session_len) > + goto cmd; > + > + if (!params.pdh_cert_uaddr || !params.pdh_cert_len || > + !params.session_uaddr) > + return -EINVAL; > + > + /* copy the certificate blobs from userspace */ > + pdh_cert = psp_copy_user_blob(params.pdh_cert_uaddr, params.pdh_cert_len); > + if (IS_ERR(pdh_cert)) { > + ret = PTR_ERR(pdh_cert); > + goto e_free; > + } ... here so that it doesn't happen unnecessarily if the above fail. > + > + data->pdh_cert_address = __psp_pa(pdh_cert); > + data->pdh_cert_len = params.pdh_cert_len; > + > + plat_cert = psp_copy_user_blob(params.plat_cert_uaddr, params.plat_cert_len); > + if (IS_ERR(plat_cert)) { > + ret = PTR_ERR(plat_cert); > + goto e_free_pdh; > + } > + > + data->plat_cert_address = __psp_pa(plat_cert); > + data->plat_cert_len = params.plat_cert_len; > + > + amd_cert = psp_copy_user_blob(params.amd_cert_uaddr, params.amd_cert_len); > + if (IS_ERR(amd_cert)) { > + ret = PTR_ERR(amd_cert); > + goto e_free_plat_cert; > + } > + > + data->amd_cert_address = __psp_pa(amd_cert); > + data->amd_cert_len = params.amd_cert_len; > + > + ret = -EINVAL; > + if (params.session_len > SEV_FW_BLOB_MAX_SIZE) > + goto e_free_amd_cert; That check could go up where the other params.session_len check is happening and you can save yourself the cert alloc+freeing. > + > + ret = -ENOMEM; > + session_data = kmalloc(params.session_len, GFP_KERNEL); > + if (!session_data) > + goto e_free_amd_cert; Ditto. ... -- Regards/Gruss, Boris. SUSE Linux GmbH, GF: Felix Imendörffer, Mary Higgins, Sri Rasiah, HRB 21284 (AG Nürnberg)