From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (NAM10-BN7-obe.outbound.protection.outlook.com [40.107.92.85]) by mx.groups.io with SMTP id smtpd.web08.715.1623167043713070504 for ; Tue, 08 Jun 2021 08:44:04 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amd.com header.s=selector1 header.b=CyUwkClG; spf=permerror, err=parse error for token &{10 18 %{i}._ip.%{h}._ehlo.%{d}._spf.vali.email}: invalid domain name (domain: amd.com, ip: 40.107.92.85, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fXuKB7mg203uIh9g1DerKMWf0f2aQMhkfqxCJwvRLP+nYjByMtAndpukobFWrdaQ3qHNytbvxtHGAQ4gJgEnnIWNQcPEhiEqRYqfC2TJ5OYeBvWUSH6ptWdXwecd59YiCQvf6OFFFR93t58O8/+TKtoZBIcZTvB9B9Jlg2h6wvwFpbE0jcfGMSRpIOBmG5Zx0DuyVJBIMmQEnD4/auHnSM14vot/9F1pyzAh0K1JDk4HngWaB4NaFfJSZpxM4OkVUAGvfQLTWn+cxRlQnNF7BrDLYGolaucU6QJWo0zOEpDiUKQbX+5DBMMd4ai2RFiEddLIBbLitfTzjrJttlhgLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nrElfWB7oFLnHV5iHQu1Ng/Uxqkmc1/Zf53gg2umBGA=; b=CkyjQY2ELP4odC20L1anqZnknVgg9uJ3VjY/M0ZykoPxhXTYbuFqMlt4SDdEQ/MGwoZquwzblBzZOvcKcuSR8XuPLGdzyDKfQZ7N3M3pVeAIsB9/rySe3VSmYiyclg7Fhkl6UVeadwGpQUzqxYuAyLW7IgsxI6JayYIqkodGMozCVafMOCKXYkGwDuN6IkrLGFbedq186ZUu4vuwpi1A/5R0ePEMCGPkaagpZxw48vjrGJHwQxcUZziUGRrgWpjVH+kDtN5x6rEKu+tIy8reVGum5cvt9SHoy46pHfpV5qh2oBkDjmFMSn/ln6bZmvflq4yHNOEUB5CfJQ4wF4XpmQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nrElfWB7oFLnHV5iHQu1Ng/Uxqkmc1/Zf53gg2umBGA=; b=CyUwkClG9R4VixQd9BPTAFkTynrklfSE2jWrDB1ESnHIrU3wy7jquyr7/l+hNTKOTMIh1pk1G8vpza4L5YJlq2ldgZpp6DmC7FJkVlhw5YvR7hfftok0ZI7N+7N1lUki2tidRJp/EwZSOjRjrH/CoN1neiY31c5OKL3HBTCPdv4= Authentication-Results: kernel.org; dkim=none (message not signed) header.d=none;kernel.org; dmarc=none action=none header.from=amd.com; Received: from SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) by SN6PR12MB2688.namprd12.prod.outlook.com (2603:10b6:805:6f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.23; Tue, 8 Jun 2021 15:44:01 +0000 Received: from SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::a8a9:2aac:4fd1:88fa]) by SN6PR12MB2718.namprd12.prod.outlook.com ([fe80::a8a9:2aac:4fd1:88fa%3]) with mapi id 15.20.4219.021; Tue, 8 Jun 2021 15:44:01 +0000 CC: brijesh.singh@amd.com, Ard Biesheuvel Subject: Re: [edk2-devel] [PATCH RFC v3 05/22] OvmfPkg: reserve Secrets page in MEMFD To: devel@edk2.groups.io, lersek@redhat.com, James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Erdem Aktas , Eric Dong , Ray Ni , Rahul Kumar References: <20210526231118.12946-1-brijesh.singh@amd.com> <20210526231118.12946-6-brijesh.singh@amd.com> <6c1d0c68-0537-9b58-ada4-ec9deb1a7c9d@redhat.com> <699aba35-c2af-f9c0-4904-e9be1032b13d@redhat.com> From: "Brijesh Singh" Message-ID: <09212544-1244-a5d2-652b-fcbd4768ba22@amd.com> Date: Tue, 8 Jun 2021 10:43:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 In-Reply-To: <699aba35-c2af-f9c0-4904-e9be1032b13d@redhat.com> X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: SN7PR04CA0194.namprd04.prod.outlook.com (2603:10b6:806:126::19) To SN6PR12MB2718.namprd12.prod.outlook.com (2603:10b6:805:6f::22) Return-Path: brijesh.singh@amd.com MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from Brijeshs-MacBook-Pro.local (70.112.153.56) by SN7PR04CA0194.namprd04.prod.outlook.com (2603:10b6:806:126::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.21 via Frontend Transport; Tue, 8 Jun 2021 15:44:00 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e56a37cf-9f6e-4685-53c7-08d92a943c7c X-MS-TrafficTypeDiagnostic: SN6PR12MB2688: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5236; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2LAqRxxiVpYT+8KmJfSaKrqMIjnf5dRF0dId3XUnfy9ff5HtdrcP5bMjPSExrgbP0zdq0xELQr7g1AIP+ecb32JtpqirrjoyhYw998PETk/r3095HAMhgYM6afLX1xZYjPPK9zOcvmtUZWD0p1EFNCfNcsOpk4O2HondcdmYktEsyE45q7IDqITddjoMnIiuYZH59Q4KWdJnvyoGVsEzkRvwXHYCHRA6svJrgmqdxKqM1K14bsHRdVOnDP5c5fsI+nMjqTyPXc5AaO1bl9bDhTBWFym7X3gKwwBtvkldn8/VEeofo1JvuK3rZMDoo6mbcrWO9uxscVGuEyOuNm2OMO4aApi6B4kcp8j+pjQXj9miIFo3oZkzMZoBVYlp9vAo2jSf2l7JNsvdJphLVkLyLvka5oij36jo3QY033cQwhO57xJo3bla+4uLCWNeCapHVZVLRIU+5ugSP4aSth3aPy5tXrr89wi5Q2Fl6Ifn0hNsH7L4/KuUqYwasiPzqQ5BUqVyNGBt3p9wy8SavUocPMTmEjubIMPbo3c1N2kTWmz4YEfDzQYG/qtla1knafVUvFBgsulwpj+sUTqus4EkwO+TZP6rcXRDiNgeUUf5GQIcjj4fYfNGcMlKhBa7nx1pAqigQv36khIRxEeTLAiEIJmu4ZaH57rdzE8/DnDpv3Pd0yZkN74WjK8wFXzjMYzK8TLX7Ns/8/d0AXFohOFOcZHYJ8t8UhHDTEXh3EDvjIpD6sD8Bi0L1EwpzIqper+GeA0SLqu7yzYU9St7djVAgjPHBnl2m9/mfYgxM2npgEnYSG6RtQJLgB9EYK4dbIfhh2WDq363odT8Jnc64TvyFv1DUMvaXgQ/jPrhJneN4/Y= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:SN6PR12MB2718.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(346002)(39850400004)(396003)(366004)(136003)(376002)(110136005)(66946007)(16526019)(5660300002)(38350700002)(186003)(38100700002)(4326008)(66476007)(52116002)(8676002)(966005)(2616005)(66556008)(956004)(2906002)(316002)(26005)(31696002)(36756003)(6506007)(31686004)(921005)(83380400001)(45080400002)(478600001)(6512007)(86362001)(44832011)(53546011)(8936002)(7416002)(6486002)(43740500002)(45980500001);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?n04B98Xz3Uw3JJIbTXFc2AYGkZjfBJ7NIBpu1ooS+FRxg/+m+OYS4A94K0K9?= =?us-ascii?Q?gUUS2q3zYzAq8P5V/uW+L/rwUYkutb7zKmUq4X8bzL67dPGI2aOB7QkBJ+03?= =?us-ascii?Q?RCVIqxdqVruk4nxG/bPgrrHsD/CCjzGftwYiHwAe3cGQTDvtA2f5EZZPJ9/S?= =?us-ascii?Q?ZnRsURFPtl856AhijHrIKDiBmIlmKJ2CvarBCr/l1H7psMvsnrYewWQOgY8o?= =?us-ascii?Q?vfClfLgpuOaUx6L+Dtp6yRKyBrqNDXwuXcuxVrMQFLb6kH5CX0EIrZ5XZfEG?= =?us-ascii?Q?pSwtnzCQKlAaL7BHaUofDkfxAYkiixsIwv+F6/a8NS9t2HJHa3lHFBsCAbsJ?= =?us-ascii?Q?m1yqEPOceev6lVCNtSRLwWQZHbdM9x2NRJJHQ6BvAfui6n8qYm9InpaiQ8pW?= =?us-ascii?Q?sRyKeWxK0T8i2yPkg9LOvoxbyDrfd/aDVx5BzgsbrwqESvoS84McKVSVuDTk?= =?us-ascii?Q?rZJS1YVQma6PLWwQIfnEQZR33KuA7Nuvh3wfKNzyaGGXr7v9T1wJRQPK2eyO?= =?us-ascii?Q?64EQyDwYLNlADs+cScdL/6qokWfLk4jYqJqppcal3VgMOHMZrB7azBJYu2pS?= =?us-ascii?Q?gYPziEWyATCj58N98KiODMjno72c4+zYlrPfkmMryk1hCfdOg+QDlQTPkTvW?= =?us-ascii?Q?O92Bo1GYPsgPO/oBoY5OnnOXotuA07HM0KnI14FEEe2Y8RGlUWmkTOskJVqr?= =?us-ascii?Q?1XsP3moi9giHLgJckMI4ASJEqd+kjw3La6GbT7B61r/7iWYjuCscJFJDJYcC?= =?us-ascii?Q?PIM6cIvMZzxi60QE5smmxJcgUj6DRJP97a/DnoH2Imyr8PLXXVRh14AsF1+p?= =?us-ascii?Q?JI6/YnSfBDKj9Zzumi81sjX9Qr1EZO/bkTeMCblN8bs8ivK68aFGDjRao8GS?= =?us-ascii?Q?oJQlGvC4a0wj4fNo8vgu4VBmwZCFELMh1CjyC6jvUcyl0a4rjl6waMVmHpbi?= =?us-ascii?Q?cqm5wBWfRDDNZRBwlPDkLITA518wi6cNVM6seZF9ID9qtFwrNuY0A8X28VkB?= =?us-ascii?Q?s9ocGe4piMYro/Mt/yXbp9Cq4yuvRvohakAFhN5f0TMO22UI5QlECD6z1G+T?= =?us-ascii?Q?gbm//o+c20BofUxNMSx1d6TYf+emcj+1Hn5LZSstaMBR7hiYBRYKSjj8HStl?= =?us-ascii?Q?nQBTixYHKAGu6KDbVchgc6BtKycXKnPeeVC9QHdtAxjx3BP+TF9wIhCEsX3w?= =?us-ascii?Q?oLx/gm1wtt9qXNTsxPISj+cF0lsxRahP9f99MxsZz7AxjbJBIl+5+A73zfcX?= =?us-ascii?Q?G1gmXE7xF5v12GWnG+XEVl/Vjdo+O1R8+DWI195jFJqPkfQ10DtGg/8173bo?= =?us-ascii?Q?zeJnDs08a7cutCbgdJNTizhk?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e56a37cf-9f6e-4685-53c7-08d92a943c7c X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2021 15:44:00.9262 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 1sPcPop65UrbLF1mNV0nHyTUz1xg+ZAYk4ZPqkgwhNxyagr1grMqRoYsDqiRwrwx9nE8gYF623oRxswg3IwBgw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2688 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 6/8/21 4:20 AM, Laszlo Ersek via groups.io wrote: > > I thought the secrets page was entirely opaque to the guest firmware; > i.e., all the guest firmware would do with it is (a) cover it with an > allocation in SecretPei, (b) forward it to the guest OS via a UEFI > system config table in SecretDxe. Yes, it should be an opaque to the guest firmware. If someone wants to do attestation inside the OVMF then they may need to know the whether its an SEV or SEV-SNP guest. If its SEV guest then blob contains the guest private information (such as disk key) and if its SEV-SNP guest then blob contains the encryption key used for communicating with the PSP. > > This patch uses the same PCD names ("launch secret", where I understand > the SEV-SNP case *not* to be a *launch* secret; is that right?), plus it > uses the same drivers. That's way too confusing. Yes, its not a launch secret. With your responses so far it seems that I need to create a different PCD and spell out that its for SNP secrets page, maybe something like this: "PcdSevSnpSecretBase" Since the code for reserving the memory type and installing the EFI configuration table already existed in AmdSev/Secrets{Dxe,Pei} so I decided to reuse. Now I understand that why you don't want to overload those drivers. Those drivers are not part of OvmfPkgX64.dsc because the generic packages do not support the attestation. I will update in v4 to not use those drivers and reserve the memory during PEI phase and create another driver to install the configuration table for it. > > So what is this "SNP secrets" page supposed to contain: > > - both the previously defined SEV/SEV-ES level launch secret, and the > SNP-specific VMPCK (?) > > - how are these secret bits separated from each other in the page? > > - does the guest (firmware and/or OS) *write* to the new locations in > the page, possibly for secure message construction? > > > Either way, I think the proposed repurposing of the page, for the sake > of SNP secrets (VMPCK and maybe even secure message construction?), > breaks the current declarations of the PCDs, in "OvmfPkg.dec": > > ## The base address and size of the SEV Launch Secret Area provisioned > # after remote attestation. If this is set in the .fdf, the platform > # is responsible for protecting the area from DXE phase overwrites. > gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretBase|0x0|UINT32|0x42 > gUefiOvmfPkgTokenSpaceGuid.PcdSevLaunchSecretSize|0x0|UINT32|0x43 > >> In SEV-SNP, the secrets page is not tight up with just the remote >> attestation. > This is the most important statement. We need the SNP secrets page even > without remote attestation. OvmfPkgX64.dsc does not deal with remote > attestation. > > But then (putting all the PCD naming confusion aside), if a driver is > promoted to "common use", from the AmdSevX64 platform to multiple > OvmfPkg platforms, then it should be lifted to the top-level OvmfPkg > directory. Now I think about it maybe we should leave the driver where it is because OvmfPkgX64.dsc does not need to deal with the attestation etc. But we need to create a driver that can install the EFI configuration table for the SNP secrets page. Is that okay ? >> Later, the AmdSev.dsc can include a library to perform the >> SEV-SNP-specific attestation. The library can use the SNP secrets page >> to get the key and message counter use for constructing the guest >> message to query the attestation report. >> >> I hope it clarifies it. >> >> [1] https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2F= www.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F56860.pdf&data=3D04%7C01%7Cbr= ijesh.singh%40amd.com%7C972887a952cd48b090a308d92a5eb0d5%7C3dd8961fe4884e60= 8e11a82d994e183d%7C0%7C0%7C637587409068253595%7CUnknown%7CTWFpbGZsb3d8eyJWI= joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sd= ata=3Dj%2FL5eTSR3%2FODJRE0IaF7R49aDVkFjDCO1JUpGsPbDwk%3D&reserved=3D0 >> >> >>> Honestly I'm getting a *rushed* vibe on this whole series. Why is that? >> I am not sure why you are getting this feel, please let me know where I >> can help to clarify but the series is *rushed* at all. Its building on >> existing support. It's possible that we are getting mixed with the >> fundamental difference between the SEV and SEV-SNP attestation flow and >> recent patches from Dov to expand the attestation to cover other aspects >> of the boot flow. >> >> In case of SEV-SNP, some folks may prefer to do all the attestation in >> the OVMF and others may prefer to do the attestation in the guest OS. We >> should try to not restrict one approach over the other. >> >> >>> Assume that I'm dumb. You won't be far from the truth. Then hold my han= d >>> through all this? >> >> Please let me know if the above explanation helps or I should expand mor= e. > You should please (a) expand your *commit messages*, (b) add a *wall* of > text in the "OvmfPkg.dec" file, where the PCDs in questions are > declared. When I grep the OvmfPkg subdirectory in two years for > "PcdSevLaunchSecretBase", I'd like to find the DEC file's comments to be > consistent with the actual uses of the PCD, and I'd like git-blame to > tell me something useful about those lines, too. > I will add more comments in the patch to clarify certain things. > One problem is that I'm supposed to internalize about 50 pages from yet > from another technical specification, in order to get the basics of a > single patch. I can't even follow the *set* of AMD documents I should > have a local copy of. How am I supposed to interleave all that with, for > example, reviewing a 57 slide TDX design presentation? As you may have seen that myself and Tom try not to put the exact link or=C2=A0 document number in the comment is because we have seen that our do= cs folks change the link or they replace the old document with the new copy. We have similar issue in kernel. The kernel maintainer now have a bugzilla where they want us to upload the document so that they can keep a copy and in the commits we refer to that BZ link instead of AMD URL. I myself gets so mixed up with various version of documents. I don't like that we replace the old docs with a new without archiving it. thanks