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 D21A9C05027 for ; Fri, 20 Jan 2023 22:19:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02CBB6B0071; Fri, 20 Jan 2023 17:19:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id F1F016B0073; Fri, 20 Jan 2023 17:19:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBF5C6B0074; Fri, 20 Jan 2023 17:19:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C86366B0071 for ; Fri, 20 Jan 2023 17:19:56 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 865ED1209D7 for ; Fri, 20 Jan 2023 22:19:55 +0000 (UTC) X-FDA: 80376595950.06.C4CFDE9 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id 7F29610000C for ; Fri, 20 Jan 2023 22:19:53 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pDTcPNR6; spf=pass (imf14.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674253193; 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=DwEDlEWc6+muR5Q4cl+uUWw6ZpvlrqpdQRh6Xey041M=; b=mte3gL68STUA89Z/RPAWhcsEQeP8iMR3+kPUCWR2rGmfQBH5x2kmP5EbMG3uL4yoEGAXdK g0c/N0HgljFapQOGFLgRGhnz71dP5BHfJ+20gG2GKpPWr9dQoLkjlxjTAl3cYf9tf4teF9 iVA7uqZMfe4L3+ZceM42HTZHOvUEs88= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=pDTcPNR6; spf=pass (imf14.hostedemail.com: domain of jarkko@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=jarkko@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674253193; a=rsa-sha256; cv=none; b=sfeJBUW0kYHE+zd3Z1oUF+ReEnv6MjFmzq2e2VbXZUFA6ITKTX/LotPgnR/Z0X/3t16tRI 5lsdlJXovbBTazPLGUodSsi2Ibuy+3QCzkC0xErsi7+ccUjY+3S/sr4qfpaD3XWuOFDnxE KccdQY+/PgPkDc3YdLZD2ILg/DLyJGk= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 9E806B8281D; Fri, 20 Jan 2023 22:19:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C3130C4339B; Fri, 20 Jan 2023 22:19:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674253190; bh=HvcNM2UjecQL348bqHAOm445agwCIVqQtDTv2S/yEmw=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=pDTcPNR6BXuGBjP48njVINKN5F4mgJzV2lu2lU+SiajKyiN1d9pouPWpoFT+XvXmP p1moDyoN+5EFFREdr0oR4/QtuhG0eBg+nfymIU51LXQZjPtt4+tZSHc8kRvTMIesNi N5TKxI/AuyFae1Pod78Qp6VO3XsbPnvU8SMAyKuj05xhg6Y+YN1BhQDju7OUbzYhdT zrRiBZSrl4uuJw5bUXrzdOKEZfhl6OF9parCd9H83GKLEDxvijBfUR5wsISatx4H2+ evuGZ2pTnCHVocTM/YFfyfwP75KRtLMYIFTqZYgGjd6DKGo1p0Ps0At4i/ddziPeOm JETqPRmVwe03Q== Date: Fri, 20 Jan 2023 22:19:47 +0000 From: Jarkko Sakkinen To: "Kalra, Ashish" Cc: Michael Roth , kvm@vger.kernel.org, linux-coco@lists.linux.dev, linux-mm@kvack.org, linux-crypto@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, tglx@linutronix.de, mingo@redhat.com, jroedel@suse.de, thomas.lendacky@amd.com, hpa@zytor.com, ardb@kernel.org, pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com, wanpengli@tencent.com, jmattson@google.com, luto@kernel.org, dave.hansen@linux.intel.com, slp@redhat.com, pgonda@google.com, peterz@infradead.org, srinivas.pandruvada@linux.intel.com, rientjes@google.com, dovmurik@linux.ibm.com, tobin@ibm.com, bp@alien8.de, vbabka@suse.cz, kirill@shutemov.name, ak@linux.intel.com, tony.luck@intel.com, marcorr@google.com, sathyanarayanan.kuppuswamy@linux.intel.com, alpergun@google.com, dgilbert@redhat.com, harald@profian.com, Brijesh Singh Subject: Re: [PATCH RFC v7 25/64] crypto: ccp: Add support to initialize the AMD-SP for SEV-SNP Message-ID: References: <20221214194056.161492-1-michael.roth@amd.com> <20221214194056.161492-26-michael.roth@amd.com> <5bb741b8-8daa-028d-d920-826e1396dd87@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5bb741b8-8daa-028d-d920-826e1396dd87@amd.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 7F29610000C X-Stat-Signature: e49yn6qxp4qg6du9aswksyq9385znq7f X-HE-Tag: 1674253193-538421 X-HE-Meta: U2FsdGVkX197NdofXICLE8usLoHaTNiFDEeAnMztml+c+lf7WyoqUhJl0bGa/T+RKcGWOQt0iAjbepJCEmy1UqEiajm1vri3H//xPJWvSlIsnTuy5wiz3QwhZ34+MVfd0JYTDetdhU+dGxYpoXm7uzv496/t5bi5sHvnKZhjXN9AiD3psx2fj4SDJW0naVe7Le84zwMdrvjXNa8PUbXpt3jeOH9vLDQNbF33Xd/3Lyhq61RrZ2jaNy6WaIFicBRN/RxZ64ou5vcnC6D2YrVsC004cFku733H1p+v6uSU9y+bE2ezDbunIcenjSLkAUEjMrURqCzt7dMryxp3p9KBMH6jB+zLKXTcDBUuHC8FGb47xyt2bKBizvSrtJT4NT34FLiboDyW3c5QLuMG3r06f7Z6+nMyTSdNwwtrAoDZGfwS+bcgvlsvt/FGXuIXFw6J5WKoTT7+oFwWYdIp4PqIp2Vg7sEm8o0mQCXCMl9Y5rkws7em3ujSNdyKs2iwNCfTDGr3e1lXPw6ZLQUiuWXmctoFn79wSLM6WQeccUulnYGPYHAB34j4PHHO2QO5U8iFdTiloiE3k9MTr42Qx4GIlXscemwx9C0FPAHlIQr44kscZ48Eik5kjawUdApDLTHIYEJEhhshrV4CrenSrD/PXyE8KymUOpIcNC84gfdHw8Ta//eDGdGCn59LgUP0yTTyixUpum+EkTzmWlCpmAXI93hehSypzyRHrKDJAa/LITCqteJNUdj4zy5rmd7Io53pgHqnpgJjbFeL9w8ZBaBLTW+4SB4iY/e9ETicU69RmLGkzZ0/2oSKlSItiDrL1MFnYeOFSoARTV/+ckje3v2z7WC14ZmJ92QH32SFzI53FtxKUR/XtWo1PVaPcQ7C99c10xggmXxqVulAv93+N5RmAhURuDRj5TycZha5JO3TcXkPl9ER/Ml3oWKxMH7M7wZ9j0zwfMqSIEqk/dZxAzd W2tpO4vj 3N6zl3hQ4tMd/ZXtPAlR0wD1+O/am8VJG/9++5Fh9WaKGdAPuHU5W9gAaf1JMRRR33QrESCD/Pq7VXFmdOcb/FxOh1ybzJMXDBoGSXtMZtzhySrhEIcA2jtm72AAk2aGqMNskxgJBqXOs1DA+FsJx16F7F0gYTCmP3g/C7qwdHg5E8C6RmO0VND+DHjNZj0qfIs53XxX9cUIYKTym2SmtBH3oGkkeNPKXueA5Jy0aW3YFzgg/J6mrj/818fbOvZ4Drej2UUlG+UAKqI1/W8sAc3w3tXDo6yp6ge0j9aNzRtlflJ9FT1io1sXJqzoNFjL9NLpL2GBV33LMevI= 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 Thu, Jan 05, 2023 at 04:40:29PM -0600, Kalra, Ashish wrote: > Hello Jarkko, > > On 12/31/2022 9:32 AM, Jarkko Sakkinen wrote: > > On Wed, Dec 14, 2022 at 01:40:17PM -0600, Michael Roth wrote: > > > From: Brijesh Singh > > > > > > Before SNP VMs can be launched, the platform must be appropriately > > > configured and initialized. Platform initialization is accomplished via > > > the SNP_INIT command. Make sure to do a WBINVD and issue DF_FLUSH > > > command to prepare for the first SNP guest launch after INIT. > > > > > > During the execution of SNP_INIT command, the firmware configures > > > and enables SNP security policy enforcement in many system components. > > > Some system components write to regions of memory reserved by early > > > x86 firmware (e.g. UEFI). Other system components write to regions > > > provided by the operation system, hypervisor, or x86 firmware. > > > Such system components can only write to HV-fixed pages or Default > > > pages. They will error when attempting to write to other page states > > > after SNP_INIT enables their SNP enforcement. > > > > > > Starting in SNP firmware v1.52, the SNP_INIT_EX command takes a list of > > > system physical address ranges to convert into the HV-fixed page states > > > during the RMP initialization. If INIT_RMP is 1, hypervisors should > > > provide all system physical address ranges that the hypervisor will > > > never assign to a guest until the next RMP re-initialization. > > > For instance, the memory that UEFI reserves should be included in the > > > range list. This allows system components that occasionally write to > > > memory (e.g. logging to UEFI reserved regions) to not fail due to > > > RMP initialization and SNP enablement. > > > > > > Co-developed-by: Ashish Kalra > > > Signed-off-by: Ashish Kalra > > > Signed-off-by: Brijesh Singh > > > Signed-off-by: Michael Roth > > > --- > > > drivers/crypto/ccp/sev-dev.c | 225 +++++++++++++++++++++++++++++++++++ > > > drivers/crypto/ccp/sev-dev.h | 2 + > > > include/linux/psp-sev.h | 17 +++ > > > 3 files changed, 244 insertions(+) > > > > > > diff --git a/drivers/crypto/ccp/sev-dev.c b/drivers/crypto/ccp/sev-dev.c > > > index 9d84720a41d7..af20420bd6c2 100644 > > > --- a/drivers/crypto/ccp/sev-dev.c > > > +++ b/drivers/crypto/ccp/sev-dev.c > > > @@ -26,6 +26,7 @@ > > > #include > > > #include > > > +#include > > > #include "psp-dev.h" > > > #include "sev-dev.h" > > > @@ -34,6 +35,10 @@ > > > #define SEV_FW_FILE "amd/sev.fw" > > > #define SEV_FW_NAME_SIZE 64 > > > +/* Minimum firmware version required for the SEV-SNP support */ > > > +#define SNP_MIN_API_MAJOR 1 > > > +#define SNP_MIN_API_MINOR 51 > > > + > > > static DEFINE_MUTEX(sev_cmd_mutex); > > > static struct sev_misc_dev *misc_dev; > > > @@ -76,6 +81,13 @@ static void *sev_es_tmr; > > > #define NV_LENGTH (32 * 1024) > > > static void *sev_init_ex_buffer; > > > +/* > > > + * SEV_DATA_RANGE_LIST: > > > + * Array containing range of pages that firmware transitions to HV-fixed > > > + * page state. > > > + */ > > > +struct sev_data_range_list *snp_range_list; > > > + > > > static inline bool sev_version_greater_or_equal(u8 maj, u8 min) > > > { > > > struct sev_device *sev = psp_master->sev_data; > > > @@ -830,6 +842,186 @@ static int sev_update_firmware(struct device *dev) > > > return ret; > > > } > > > +static void snp_set_hsave_pa(void *arg) > > > +{ > > > + wrmsrl(MSR_VM_HSAVE_PA, 0); > > > +} > > > + > > > +static int snp_filter_reserved_mem_regions(struct resource *rs, void *arg) > > > +{ > > > + struct sev_data_range_list *range_list = arg; > > > + struct sev_data_range *range = &range_list->ranges[range_list->num_elements]; > > > + size_t size; > > > + > > > + if ((range_list->num_elements * sizeof(struct sev_data_range) + > > > + sizeof(struct sev_data_range_list)) > PAGE_SIZE) > > > + return -E2BIG; > > > + > > > + switch (rs->desc) { > > > + case E820_TYPE_RESERVED: > > > + case E820_TYPE_PMEM: > > > + case E820_TYPE_ACPI: > > > + range->base = rs->start & PAGE_MASK; > > > + size = (rs->end + 1) - rs->start; > > > + range->page_count = size >> PAGE_SHIFT; > > > + range_list->num_elements++; > > > + break; > > > + default: > > > + break; > > > + } > > > + > > > + return 0; > > > +} > > > + > > > +static int __sev_snp_init_locked(int *error) > > > +{ > > > + struct psp_device *psp = psp_master; > > > + struct sev_data_snp_init_ex data; > > > + struct sev_device *sev; > > > + int rc = 0; > > > + > > > + if (!psp || !psp->sev_data) > > > + return -ENODEV; > > > + > > > + sev = psp->sev_data; > > > + > > > + if (sev->snp_initialized) > > > + return 0; > > > > Shouldn't this follow this check: > > > > if (sev->state == SEV_STATE_INIT) { > > /* debug printk about possible incorrect call order */ > > return -ENODEV; > > } > > > > It is game over for SNP, if SEV_CMD_INIT{_EX} got first, which means that > > this should not proceed. > > > But, how will SEV_CMD_INIT_EX happen before as sev_pci_init() which is > invoked during CCP module load/initialization, will first try to do > sev_snp_init() if SNP is supported, before it invokes sev_platform_init() to > do SEV firmware initialization ? Because the symbol is exported outside the driver to be called by other subsystems, you need to have a santiy check for the call order, as it is a hardware constraint. Otherwise, any unconsidered change in either side could unknowingily break the kernel. Alternatively, you could choose not to export sev_snp_init(). It is supported by the fact that the call in sev_guest_init() is does nothing useful (for the reasons you already wrote). BR, Jarkko