From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (NAM11-BN8-obe.outbound.protection.outlook.com [40.107.236.69]) by mx.groups.io with SMTP id smtpd.web08.761.1623177294283067302 for ; Tue, 08 Jun 2021 11:34:54 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@amd.com header.s=selector1 header.b=j0btw9r+; 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.236.69, mailfrom: brijesh.singh@amd.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kTE3batxYrZh31oNPlqKlv95jioZeI/MdJSsJGv+dgZzdwIs81oOrKG5jsHT5NPKDE3NEhNTezxPnevwvThAokrCMbHE9nRdeTgfJR9jTIHIcLFt/xnr2nZitooA6aLVnQry2w2TlhRe1QFxHSyqfpDjUd5cCrNdwA5QQNk47K9bbBZA0Za0HSwOoYKnjlQGhEA7BDTULsB/yzdKbdZFwFOCP86dMarGpCDr1YT/lIqlX6UjD8ZFJufArEqH7C9NWIebzqcK821vlWnPO0KTt3dtm9hhAWAheX1cegabc9/fWEZ4c72LLymXcqrb1SFH7YFBY7B9rx0+U19z2yQ2Lg== 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=Hx+3pIKBRJPwt5ZRTkXJV9+xBXluGnfB2S7CHfegrT0=; b=kJ+hUm3KpQFFrUPOFyxgmjXixIdiC4XU6OItH/DsUZ0Tj55MWXYDZYzEM4Mdak9wZInxoRfbP7229Nni2fDsyVfOnEcSy/iPk8LFpW23Ia/qJDHVO2rWXe3dd4EFt3TrgX8jGghtWTJKwRDUQZXCKQRy6R8KeGTq2/h4ITyBB5iGteGarSmUHddq4PLw30m5MhuH3cGSD1j65uaKsFfb0IC5TuCDxPxiqXiwLoylOICncWUe2OMK1H9XZVqjSfldijVkvJvr9x/O7M1VkpQZIK8EtrD8Npu7eApbp9zBGdffXBl+6cM2WHjaAVW5+WFEKPqnZm3Wh2ZJ2Nbvbvm/hw== 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=Hx+3pIKBRJPwt5ZRTkXJV9+xBXluGnfB2S7CHfegrT0=; b=j0btw9r+g48UbA1/jmatAZUa6GXdrUZT9sk4RTqF79WRXZKIoBIJtzP7JITjSI1uj4IgS+aClewSHBciQS6dT0gs2uYWbqaqfN0CNSVnHm/naeeYkJTtAJlPMSDu5M4UlE0rk+emcmOy4XrThrWOKz1XCBHqAfnQYFwO4LFtrPA= 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 18:34:49 +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 18:34:49 +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> <09212544-1244-a5d2-652b-fcbd4768ba22@amd.com> <8f49cc0d-ed3a-e81e-51a2-ea22c6103ac8@redhat.com> From: "Brijesh Singh" Message-ID: <69b782c1-252b-7fcb-9602-6e780e763bd6@amd.com> Date: Tue, 8 Jun 2021 13:34:47 -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: <8f49cc0d-ed3a-e81e-51a2-ea22c6103ac8@redhat.com> X-Originating-IP: [70.112.153.56] X-ClientProxiedBy: SN4PR0501CA0032.namprd05.prod.outlook.com (2603:10b6:803:40::45) 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 SN4PR0501CA0032.namprd05.prod.outlook.com (2603:10b6:803:40::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4219.11 via Frontend Transport; Tue, 8 Jun 2021 18:34:48 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 90b8dcd3-8f63-44b9-20db-08d92aac190d X-MS-TrafficTypeDiagnostic: SN6PR12MB2688: X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HN17vnLTD+cq3zetQhp6VYlci0bOlyH+4bZHvznfOKKp1uNWoJSvRVH/2KtdE6+6ueW7gpbmW9IOQqjOKdraoLXyyX3Dl/k+grmO3TM2+Q3X8ODdXrvPjIsuF/kkD0Ornt4ymdVMzwumrUiKXP22RO+3tAsaDPEeKfG/Ul3Jo6TyHb4bIyX0M6uClYEgdKYIOdC+ewsblyIdKIs5UeRukpbpvUrZt6esZHQj6tl5QxKm1s1jY6gIxVasRzkuf/DqIpRuJKY5HzlT+a2mLy9Fz44RHzRGC77EaDux3W8mwR28822hSDAsVsDYbJpgMbUcce//SbGVlC2jGdfvjE8ZQkY+FGCnRUDD9Wd4NFPT0jeDoNNYsKpX2/eMNrE1ZaFIiaYIFEIstGxRdLZqGYBYO6MBbPhoaTZ5WiQRcIQTPf7y/kVStUWim+/6vNLorYiDB6O3XhT/e0AGSsgmkdzQZFrhiP5eZ4B9sVNzi63rQh+HQrVpeRmXS68w0gr33RPPgVjnPkXNaJLdWrqwF6j4OENQSJp6g8iqKxR8S5WJJ7kwz+CK1ZsFn0+KOwhplYhEzhe9sNg88i9ztXM+Ia6fFFedl8cZ/3ncVmTiKtoLj0JbNdcHn8xxo4/7Bg7j5/HCu7IN4BKiD1wmG/Cm2mNMDXXL/4vv5nHBNheqEkGluZLIPNHEfdZ3KmGVmR4n/7YPOvzubvWRo3x3W2rSaXzuXJN+GppDbL1GyhEVti3sChN2U+ZffZ7OcznqiTdgVcVMPWBSlk1dB6+kAZKJefbV7ZRd65E0eGmQUruh5TzP/J90jUztc1e79q0a8O/ToMyax184UVXPo15cTCMmU3WkBTetbNfdt1fKsOgCuoGjXTY= 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)(366004)(396003)(136003)(346002)(39860400002)(376002)(110136005)(44832011)(66946007)(5660300002)(16526019)(186003)(38350700002)(38100700002)(66476007)(8676002)(966005)(52116002)(66556008)(956004)(2616005)(316002)(2906002)(31696002)(36756003)(26005)(6506007)(921005)(31686004)(86362001)(478600001)(6512007)(8936002)(6486002)(45080400002)(53546011)(7416002)(83380400001)(4326008)(45980500001)(43740500002);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?74ADcUWj7pd51uLZ3iLjvx7Ge2JSw5FVThy9lPKP68uhVdK2uREwEWZU/+Pt?= =?us-ascii?Q?IgOcjlbVUcEGUiTWaeaxo63EN0oDomfTdPrdp+YheVsME4EZ9lAzN0yPoZYk?= =?us-ascii?Q?3C8aCPKADEu0VajWJH8Jys+9twxkJOXi+E2NW5f2PpbZOjBLD8GseC4qmzeo?= =?us-ascii?Q?XZYM9cDu1EaSs41JRqOaUJ+5Z09/8OTAR9HDILWgf4heHUL/2lGSlfAFIOb3?= =?us-ascii?Q?nty2oQ8wkHSWOphXEuSHlLqlpxB69FxJ8liVFXbEGmBw7DnDUsfN32iQKriL?= =?us-ascii?Q?dumOBccpNZvGHvBT2xgYJGoYMf7oTxntShI+xy5mnuZ/kcdnonmD2Jyava8K?= =?us-ascii?Q?NXDXAdNPqLfyYatsv3amYvpPmIzXVbxA+3Tu0vqulhks2ygjGw7zPZDUrzHZ?= =?us-ascii?Q?H2mIu/oIbLkXays9gqoBHMx84wL2QsgmZA225ErZbPFi7VLsDkfy+HmI5LAS?= =?us-ascii?Q?4CcomFBQr9GB/yEtk84hPMeaRlePFDyVOhZ5OynPokjzNHyt2y3kUns4Gw0g?= =?us-ascii?Q?UiHE476Lq0v2u4LMdB6KPV0nrOSuNCukDuMKWCNsTek0qRsXwjma6GPrQHq1?= =?us-ascii?Q?VIA5KEBtRNZln89Wd8wKDeli1678ARRyYQdAuRZZNbLrQVD8M7akapMrT0Mk?= =?us-ascii?Q?sPQhJhl2UfLsT78NF0MT5t5OpsklWKyY7Ykv7R5vME7oMG4zBYzQ1TWZxOu0?= =?us-ascii?Q?VzFLYdi6M3cY/scwuYKzNKeJ1xX8aQFjtYmdRXT7mdnIrUf4JByW4dFic1CF?= =?us-ascii?Q?1sXw2u5zJiBufvcuvkh5eBSkwqOR6uB1gfO+AT5mMNSXOnAG5KYUq9vmOoL7?= =?us-ascii?Q?yUQc5/dh+KtmS/i7HonaKucq4+A6d9sOl3HSbPwjtGyGp1qrEgEHyYLUFkvF?= =?us-ascii?Q?z+joDkqLm4igt6c+k4OR8V9Cbw3BzqJrnS0JNz00qsLlbKCyvVn5r75hl6zb?= =?us-ascii?Q?MZQhhz76FU2pN17R0yDQ8kmGAKWa0vvBpQTS6jCn+7azTjpoWEFPYiGlUNNY?= =?us-ascii?Q?P9t/Hwrn6Giiw/jCIfWiAS3/SgKUIEr4lq0yA3U2CzPvRLASWJSQAtP8YfJZ?= =?us-ascii?Q?X/2U+aWedsJpqruSoBxblpssl5wmJnsC4PCBOFt4i/WbaGj2I8QMHZ5ohTpR?= =?us-ascii?Q?wwJ0OyQJLudwZCF26aiUWGTItmdBtK9veEIpJLhy6OGmuLrkfKquWhvrvoXv?= =?us-ascii?Q?3wDrTJqcML5KoM22F2apdWaKS9UEUc3TmWkTW22cwbzuo9NO3H+0YITXja84?= =?us-ascii?Q?43CPwgPLA54ECZhtf30lpjmOOKNs3aBcGAxJASV1eWgjxB51wPfbU+O6xJim?= =?us-ascii?Q?C+K6ZPYlvreyTf38zc6coYdM?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90b8dcd3-8f63-44b9-20db-08d92aac190d X-MS-Exchange-CrossTenant-AuthSource: SN6PR12MB2718.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2021 18:34:49.4417 (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: 0/CUUR/UfXpnmnnISIU6yOPvbg6wkaP0JNas/Kt+8uR6Xe33EWEHHKZODxy7JsUYbI1UNLJS5Wh4zRYDLDI5Rg== 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 1:01 PM, Laszlo Ersek via groups.io wrote: > >> 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 ? > Well I'm sure I'm day-dreaming, but here's what I'd like, all at the > same time of course: > > - to-the-point PCD names and explanations in the DEC file, > > - minimize the new pages carved out of MEMFD, > > - make sure that this new SEV-SNP secret page is reusable (at least > conceptually) in the "AmdSevX64.dsc" platform if necessary -- it may > exist at a different base address in that platform, but the mechanism > should be the same, > > - I wouldn't like a new DXE driver for installing this new config table, > and I also wouldn't like to move and/or reuse SecretDxe. Instead, I > might like some new code in the existent AmdSevDxe driver, which is > already the SEV-specific platform driver (also included by the > "AmdSevX64.dsc" platform). If the config table cannot be installed in > the entry point function of the driver, can we invent a suitable > protocol notify, or other event notification callback? Yes, I will try that approach. > >> >>>> 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%= 2Fwww.amd.com%2Fsystem%2Ffiles%2FTechDocs%2F56860.pdf&data=3D04%7C01%7C= brijesh.singh%40amd.com%7C8db4f78aad5148606b6608d92aa789fe%7C3dd8961fe4884e= 608e11a82d994e183d%7C0%7C0%7C637587721344269131%7CUnknown%7CTWFpbGZsb3d8eyJ= WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&= sdata=3DroXIS4GuBJg3ftf5lQyFwItfDXQ8oHukiN0wolvd8Wg%3D&reserved=3D0 >>>> >>>> >>>>> Honestly I'm getting a *rushed* vibe on this whole series. Why is tha= t? >>>> 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 an= d >>>> recent patches from Dov to expand the attestation to cover other aspec= ts >>>> 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 h= and >>>>> through all this? >>>> Please let me know if the above explanation helps or I should expand m= ore. >>> You should please (a) expand your *commit messages*, (b) add a *wall* o= f >>> 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 b= e >>> 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, fo= r >>> 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 > Huh, so that's been intentional? I didn't expect it. At least I have been asked by it in the kernel ML folks to avoid using the moving URL. So, I am doing similar thing for OVMF commit messages. > >> is because we have seen that our docs >> folks change the link or they replace the old document with the new >> copy. > Changing links is tolerable, as long as previously released versions > (identified by document# and revision#) remain accessible forever. > >> 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. > This is a fantastic idea from those kernel developers, and I'm scolding > myself for not thinking of the same. > > If you do upload such documents to the kernel bugzilla, please feel free > to refer to the exact same (kernel bugziila) URLs in the edk2 commit > messages, and (perhaps) code comments. There's no need to upload the > (large) PDFs to the tianocore bugzilla separately; I trust the kernel > bugzilla instance to stick around. > >> 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. > Hm, so the old docs do disappear for good (not just the URLs but the > docs themselves). In that case, please let us go with kernel bugzilla > attachments. Yes, it simply disappears hence my frustration. I have ran into cases that during the review the doc gets updated and my code gets out of sync with the posted spec :(. I think some of this has to do with the feedbacks from other hypervisor folks on SNP mailing list. I am hoping this gets stable soon. SEV-SNP FW is still in 0.9 and I hope it moves to 1.0 sooner for the stable APIs. Anyway the good part is that none of these affect OVMF. Since early SEV days we have tried best to avoid expanding the blobs in the guest firmware and OS. When its comes to attestation then we have no choice but to define the Secrets page layout to access all those keys etc. In future I am sure someone will work to extend AmdSev package to provide attestation for the SEV-SNP and at time they will have much stable layout to work it. Thanks