From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by mx.groups.io with SMTP id smtpd.web10.5243.1622792034796483800 for ; Fri, 04 Jun 2021 00:33:58 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=DEW5D379; spf=pass (domain: intel.com, ip: 134.134.136.126, mailfrom: min.m.xu@intel.com) IronPort-SDR: jP53PItg6abJ2Qz+IpYP2rwL9u7SwYlza5xiqJg7Fhe6Z7KWNchRq0VEXo8twaUK7/KZd6JLz/ 5RM+9onM84Ag== X-IronPort-AV: E=McAfee;i="6200,9189,10004"; a="191579832" X-IronPort-AV: E=Sophos;i="5.83,247,1616482800"; d="scan'208";a="191579832" Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Jun 2021 00:33:46 -0700 IronPort-SDR: nOmL9Bn9TlPQPklUqRz8bGMc3tbFLz5iecmKHrNGDUp+oy9uwfGwKgQdBf7CWbPtLUXP8A6DKH 3MvxN1AZtohQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,247,1616482800"; d="scan'208";a="412280282" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by fmsmga007.fm.intel.com with ESMTP; 04 Jun 2021 00:33:46 -0700 Received: from fmsmsx608.amr.corp.intel.com (10.18.126.88) by fmsmsx601.amr.corp.intel.com (10.18.126.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Fri, 4 Jun 2021 00:33:45 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx608.amr.corp.intel.com (10.18.126.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Fri, 4 Jun 2021 00:33:45 -0700 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (104.47.59.170) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Fri, 4 Jun 2021 00:33:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UluGRQJhqi/HX5e9yqFZAJe+3HCGd95di8GmPWumKrPpT+QDcYZH9QgTuVUHDpgg6zZ6VkXDWdI2qA3efNj+Y0qczMN3e6mz8K64S7BcE+ANr+MLsMe/lLzuWsm/qvw8az6ohvPUEkayKG1fLVKyjnoiB2rpju7jLJya8mZurbR1L8wOR1K5W9Vy/G/fkMU3ECAw3VPUJud/EGUoOv9NfDNY6l+1FbzDs3hz6hEhd+08V3xme7rBkqRweyTlpYXhbhyACcqBgRvrL3pq5aEkj1hIyJouM2cPexyC+cnHPK3PisJvCSm8GpVIfMBnkNmSCES5Vyhw5NeSLcaUThuoAw== 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=FfH6a7Khro0ZDZXoINEv5iAlbbHwoeA0fiwDkQc1otI=; b=mzhG1qefv72mt/J6IVUBqqYgRVXaChQX1x2wPJX8ky63FVjh3iesAwBt5Mc9RcQ6gVkLeWUBMFSTmwvNLUvnOeVMXYTISwbOvgObBM/W6y3p/Ski1DIVcUCqI139xGpQciSCrQ0Nm+WuBSJf8peRxf6K9oxUfxfvRDMpsCoGBqLv2+O9swYA1qkXjiWvlfmRTfcDziNJcmtvDy1mUdSkfRMv4QIFum48ULqx/a/LfT8aaVSJMZwPGbNt13Y+hzFezRXWAwjGlscRyER90cTj5DWRUjQhanu8zD1qECLFFdqgv0Y/Iikqw9EBBKJ3iisJcZ1ZwWpekFcy9ZZ2ihJXWg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=FfH6a7Khro0ZDZXoINEv5iAlbbHwoeA0fiwDkQc1otI=; b=DEW5D379F0ruO/MBypFbUCdQpWwsDYYKE+xfCRDdbOmNuLpRtQz7SfgfxWqPCVAJXIlL63jeXfqQ3tUTlXzM3I/pEbvwlJoFvd66/TIBTgsBZPUw+quksdSmghFTNHiaL4zShshE5KgxqQ0l+OL05/5TNgG6jKMLIczuNXn6E5Q= Received: from PH0PR11MB5064.namprd11.prod.outlook.com (2603:10b6:510:3b::15) by PH0PR11MB4822.namprd11.prod.outlook.com (2603:10b6:510:39::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.21; Fri, 4 Jun 2021 07:33:44 +0000 Received: from PH0PR11MB5064.namprd11.prod.outlook.com ([fe80::b4be:3994:dd4d:7b9d]) by PH0PR11MB5064.namprd11.prod.outlook.com ([fe80::b4be:3994:dd4d:7b9d%8]) with mapi id 15.20.4173.030; Fri, 4 Jun 2021 07:33:44 +0000 From: "Min Xu" To: "devel@edk2.groups.io" , "lersek@redhat.com" , "Yao, Jiewen" , "rfc@edk2.groups.io" CC: "jejb@linux.ibm.com" , Brijesh Singh , Tom Lendacky , "erdemaktas@google.com" , "cho@microsoft.com" , "bret.barkelew@microsoft.com" , Jon Lange , Karen Noel , Paolo Bonzini , Nathaniel McCallum , "Dr. David Alan Gilbert" , Ademar de Souza Reis Jr. Subject: Re: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Thread-Topic: [edk2-rfc] [edk2-devel] RFC: design review for TDVF in OVMF Thread-Index: AddYf4DUPECuZ9ubQaOwhq0M0PgYbAAE6sKAAB1uQjA= Date: Fri, 4 Jun 2021 07:33:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.5.1.3 authentication-results: edk2.groups.io; dkim=none (message not signed) header.d=none;edk2.groups.io; dmarc=none action=none header.from=intel.com; x-originating-ip: [192.198.143.25] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8214f61e-564e-4e73-77b2-08d9272b1539 x-ms-traffictypediagnostic: PH0PR11MB4822: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:635; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7qAAZlnNfyqNF4i/E3CLa+UnhKBLBEqaOUjH6j09DQYMas9sb/G943vPoQs6/ZfZPn+2y5wEJuzsJFbP2+QF8Sobt870+cj1La3cdpr+vO7qUOll4yuaL0a+1kJ6Q+CBR0AZ68lZLG9fg+mY1lchJVe7MmYoKzfA2WOOxB3iGA838Ksj5HHwtjXgWrTyiDCrSoEuwDzoZD+MzL9SfOSPCEStRd3ZQuMyVB0bCMsQpQ+RVVXHCDZN9LHHSV0fdmZdZd3cDHLY0BmvFqqA3sRRMRc7f2Gd2sCfNOJo57Y4GC4y+nkRXAEWcO40rzOMYr/vBf0adwBgFNJb2C/BP9yjXUQMvfkOaA1/rzfjR6EH8uEAF2hdABE+orcKVPv/pmW4Q1vIjqJcMfdV6GAL1H4L93h94Efz4vLuhsUTdL5bQJM/LJfbZS4ve/qLZN/zI5hyrd7EH0/auT3tCPbFiWp0o70oqtLTpMHcps8LK7kwjaBw0Fno+VSc5oAYD+66ljI3x/35W4a0UOhPzj4ZwhgAVbtVDXjsc1DzIgEzn2EcLC5eE2XulUo1hlmeA3AUPtc6ll5A8ZnDqwaUtyGWgjdWZsbdbcrSBh6sNL66ZbFKrOBUI5LcuXNZo0LXFyglB0jLCDU6Xk2d3a9IpJGLHyyPMxNrUMmxbp/NXw/j9I8DOAhrhZUz4+P7Z6f4vgKcy0DdtAneTudlbeOA5cF16Wb1sLJ5bfaHwEm16hiRahc4CzKHHaOVYR+YmWazHXD32LH3SrWvbaeGYSIVBObK9D/jdg== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PH0PR11MB5064.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(376002)(39860400002)(136003)(346002)(396003)(366004)(186003)(53546011)(26005)(6506007)(966005)(2906002)(7416002)(478600001)(76116006)(66446008)(66476007)(66556008)(66946007)(316002)(64756008)(83380400001)(110136005)(54906003)(4326008)(33656002)(122000001)(71200400001)(7696005)(52536014)(5660300002)(9686003)(8936002)(8676002)(86362001)(38100700002)(55016002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?xQMagWQcbo8idQsTII97rx9JxN1Hm31pogaW6aTj4Cm9+7Un6yTzrfSNQicC?= =?us-ascii?Q?nkfvZBv7GW4vRfJn8jBl8fO4w6FF2SukbiXHOPi3M0faiRes3zelDaZkto0k?= =?us-ascii?Q?2dwzw0bq/qmTVtXajVt6OIo2lOr7S2N0KN97BV3ZqVzZJn10l0QPmxf2lhlk?= =?us-ascii?Q?GlTVkDZ87LP8sNoAd0BVcat6GPvH+K37jFbdrdaiBqZGYzePSYubyfGDScnL?= =?us-ascii?Q?9YQYZt7RsUVM8kiKP2+tF46z8qU33sN+c4oUMain7mzmSSyzQ4cjNRjH1a8f?= =?us-ascii?Q?CFAIJPcjcV9Aq2zc00/HPu5gK2HliO3EpfLnrgkiRm2TRzxMfmdCtYfRwHdQ?= =?us-ascii?Q?B6RpWyiwqmg/a5gZx+5PHX9iDScLRhO+nx40iWrwsoSFJv0NDbIll+PqXj0t?= =?us-ascii?Q?PSQ2A99ZCQR07LxTjChk80Z85OhjyLdCVp50L+LD2JBlJgrK+jBgMIlPEG6a?= =?us-ascii?Q?eqcd2ycsCTIThGdoLuAnBCpBSlaMggPpFBiS7wrNe/iOHq5St4Lz9pWchHtn?= =?us-ascii?Q?H4FR1dISUou4Dt9ksNOiwVNMkKR0Z5drC3URUcFnl6G/UUfYQY/0SWknaPiA?= =?us-ascii?Q?ZvZP4eqFEmUUn32x+9ibsU78NOIVkDeyaMJgEZvhQdM2cG0WMh4OCEZCqPl1?= =?us-ascii?Q?dge2XOvX+xJlRYoN4b8Ux/7X5WU+D+1TM3sS+LJN6jAQaBInJhQd5N4/r1wn?= =?us-ascii?Q?KIqbfxPdFgYCPlJKm4yaMsCEEs40I1g4UK33iNoiR4qK16nAn7f0E4EaYJCm?= =?us-ascii?Q?iGNv39vOTYT2zXirRzvktzEDzVhtRO35ZL5/f9qnv8G0ZJvqC7Cgx+rzpONM?= =?us-ascii?Q?XijroVXC3YxKH2bhhp7vyQTlH4r3ytxiwm0PTkReORwzGD8mViOVa7LHg5ii?= =?us-ascii?Q?MZFlJYHgOikrxwOv4DFDNgTYLrm9w2J4K+HO3dKABUluif0ANyuY7XQlqDVQ?= =?us-ascii?Q?JcVnS9CZ59ffCWfq/CXzUKDv2heuwVOXdMoIh8hUT9fj76wgRnb3D3ZYuPHm?= =?us-ascii?Q?RAIKnxPxZly/Evfz2c/kRQkmORbMped2vcVY+EMcpla7hMI3EUnUwieB1Q1i?= =?us-ascii?Q?0owwVKEWjBf7YBGkAyfpteLfe9SYU6L9wHOwUrIBga9mnQFk0+MMHsI5zcsq?= =?us-ascii?Q?SL00ItLXME3UlmVvfWvZBN0NGHk/RGOaFf5TmNyAeKm/IPzl+YEV76/iPbcT?= =?us-ascii?Q?4Lq0rrxDt6JNHJnrLxexVOa2LBXBg37Lf6BcoltR6xxIFddniqMnzNHpoUwR?= =?us-ascii?Q?Sy+dkKtKgUN4CKDKO8K4/lDu0obspTxc++IDMI3vf8l/pO/OtallfksfqUKy?= =?us-ascii?Q?Agbfb/MESk/nJaLDgmgu32GU?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB5064.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8214f61e-564e-4e73-77b2-08d9272b1539 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jun 2021 07:33:44.1864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ix1Af559+76oIL58QFL4WI4U9R4sSjLrDsWRSBbfcLj+fUNDp1/WUwdzC7hJJasdV1A6uREEX8HIZ7PP84kHLA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB4822 Return-Path: min.m.xu@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 06/04/2021 12:12 AM, Laszlo wrote: > On 06/03/21 15:51, Yao, Jiewen wrote: > > Hi, All > > We plan to do a design review for TDVF in OVMF package. > > > > > > The TDVF Design slides for TinaoCore Design Review Meeting (Jun 11) is > > now available in blow link: > > https://edk2.groups.io/g/devel/files/Designs/2021/0611. > > > > The Bugzilla is https://bugzilla.tianocore.org/show_bug.cgi?id=3D3429 > > > > > > > > You can have an offline review first. You comments will be warmly > > welcomed and we will continuously update the slides based on the > > feedbacks. >=20 > Resending my earlier comments in this mailing list thread, with the feedb= ack > inserted at the proper spots that has been given in the off-list thread s= ince > then: >=20 >=20 > *** Slides 4, 6, 7: the "one binary requirement". I would like to hear other reviewers' comments on the "one binary requireme= nt". >=20 > (1) The presentation refers to "OvmfPkgX64.dsc" as "the one" on slide#4, = but > then the explanation for the requirement, given on slide 7, speaks about > "common attestation interface". >=20 > I think we have a misunderstanding here. The "OvmfPkgX64.dsc" platform > indeed contains SEV, SEV-ES, and (in the future, will contain) SEV-SNP > support. In that sense, adding TDX support to the same platform should be > (hopefully) possible, at the cost of ugly gymnastics in the reset vector. >=20 > But "OvmfPkgX64.dsc" is *already* different from the remotely attested > OVMF platform, namely "OvmfPkg/AmdSev/AmdSevX64.dsc". >=20 > The latter has some additional modules (secret PEIM and DXE driver), it h= as > the Grub binary built in, and -- probably most importantly -- it trusts h= ost- > originated information less than "OvmfPkgX64.dsc". >=20 > For example, "OvmfPkg/AmdSev/AmdSevX64.dsc" has a dedicated > PlatformBootManagerLib instance, one that ignores the non-volatile UEFI > variables Boot#### and BootOrder, and ignores (thus far) the fw_cfg > originated kernel/initrd/cmdline as well. >=20 > It remains an "area of research" to see what else should be removed from > the traditional host-guest integration (which integration is usually desi= rable > for management and convenience), in the remotely-attested boot scenario. > See e.g. > . >=20 > My point is that the "one binary" that the slide deck refers to (i.e., > OvmfPkgX64.dsc) might prove OK for utilizing the Intel TDX *technology* i= n > itself. Simply enabling OVMF + a guest OS to boot in a TDX domain. >=20 > But "OvmfPkgX64.dsc" is *not* the "one binary" that is suitable for remot= e > attestation, which has a much broader scope, involving multiple computers= , > networking, deployment, guest-owner/host-owner separation, whatever. > For the latter, we needed a separate platform anyway, even with only SEV = in > mind; that's why "OvmfPkg/AmdSev/AmdSevX64.dsc" exists. >=20 >=20 > *** Slides 8-9: general boot flow -- TDVF; TDVF Flow >=20 > I'm likely missing a big bunch of background here, so just a few > questions: >=20 > (2) Not sure what RTMR is, but it's associated with "Enable TrustedBoot" > -- so is a virtual TPM a hard requirement? >=20 > ... Back from slide 10: "TCG measurement and event log framework w/o > TPM" -- that's curious. >=20 Comments of Dave & Erdem are pretty good to explain what RTMR is.=20 > [response from Dave Gilbert:] > > My reading of this is that the RTMR (and another set of similar > > registers) are a TDX thing that is like the PCRs from a TPM but > > without the rest of the TPM features; so you can do the one-way > > measurement into the RTMRs just like you do into a TPM PCR, and the > > measurements pop out somewhere in the TDX quote. Just like a TPM you > > need the event log to make any sense of how the final hashed value > > supposedly got to where it did. >=20 > [response from Erdem Aktas:] > > +1 to David on this. TDX provides 2 kinds of measurement registers: > > MRTDs and RTMRs > > > (https://software.intel.com/content/dam/develop/external/us/en/documen > > ts/tdx-module-1eas-v0.85.039.pdf section 10.1.2) . MRTDs are > > build-time measurement registers which are updated when TDX is being > > created. Once TDX is finalized (before the first run), the MRTDs are > > finalized and cannot be updated anymore. On the other hand, while the > > TD is running, TD can extend RTMRs through TDCALLs which will provide > > TPM PCR kind of capabilities. >=20 > ... Back from slide 43: feel free to skip this now; I will comment in mor= e detail > below. >=20 > (3) Prepare AcpiTable -- OVMF fetches ACPI tables from QEMU; is this a ne= w > (firmware originated) table that is installed in addition, or does it rep= lace > QEMU's tables? >=20 > ... Ignore for now, will comment on the MADT stuff later. >=20 > (4) Does DMA management mean a different IOMMU protocol? That is going > to conflict with the SEV IOMMU protocol. Depexes in OVMF expect one or > zero IOMMU protocols to be present. >=20 There is only one IOMMU protocol. We will merge TDX features into the curre= nt SEV IOMMU implementation. Td or Non-Td will be probed in run-time, so th= at the corresponding APIs will be called to clear/set the memory encryption= mask for SEV or the shared bit for TDX. > ... Back from slide 40: feel free to skip this now; I'll comment on this > separately, below. >=20 > (5) Enumerate VirtIO -- virtio enumeration is PCI based on x86. But I see= no > mention of PCI. If you mean VirtioMmioDeviceLib, that's no good, because = it > does not support virtio-1.0, only virtio-0.9.5. >=20 > ... Back from slide 42: I got my answer to this on slide 42, so don't wor= ry > about this point. >=20 I will comment it in my later response. [...] > (6) The PEI phase is skipped as a whole. I don't see how that can be > reasonably brought together with either "OvmfPkgX64.dsc" or > "OvmfPkg/AmdSev/AmdSevX64.dsc". I guess you can always modify SEC to > jump into DXE directly, but then why keep the PEI core and a bunch of PEI= Ms > in the firmware binary? This is because of the *one binary*. In non-Td guest, Legacy OVMF still nee= d PEI core and the PEIMs.=20 >=20 > Also touched on by slide 9, TDVF Flow -- PEI is eliminated but SEC become= s > more heavy-weight. I have to admit SEC is more heavy-weight in Td guest. TdxStartupLib wraps t= he whole stuff in SEC phase. >=20 > Wouldn't this deserve a dedicated, separate platform DSC? The 8-bit/32-bi= t > branching at the front of the reset vector is a smaller complication in > comparison. >=20 > Slide 6 references the mailing list archive: >=20 > https://edk2.groups.io/g/devel/topic/81969494#74319 >=20 > and in that message, I wrote: >=20 > I'm doubtful that this is a unique problem ("just fix the reset > vector") the likes of which will supposedly never return during the > integration of SEV and TDX >=20 > See also: >=20 > https://listman.redhat.com/archives/edk2-devel-archive/2021- > April/msg00784.html >=20 > where I said: >=20 > It's not lost on me that we're talking about ~3 instructions. >=20 > Let's keep a close eye on further "polymorphisms" that would require > hacks. >=20 > The first 9 slides in the presentation introduce much-much more intrusive > problems than the "polymorphism" of the reset vector. Would I be correct = to > say that my concern in the above messages was right? I think I was only g= iven > a fraction of the necessary information when I was asked "do you agree 'o= ne > binary' is viable". >=20 > [response from Erdem Aktas:] > > Let's not worry about this for now. We want the one binary solution > > for practical reasons and also for simplicity. In the end, we want to > > do what is right and good for everyone. > > Those are legit concerns and I think what Intel is trying to do (sorry > > for mind reading) is to discuss all those concerns and questions to > > make the right decision. I really appreciate their effort on preparing > > those slides and bringing it to the community to review. > > > > I will also read your comments more carefully and provide my thoughts > > on them. > > Sorry for being a little slow on this. >=20 >=20 > *** Slide 10 -- Key impact to firmware >=20 > (7) "CPUs are left running in long mode after exiting firmware" -- what k= ind of > "pen" are we talking about? Does a HLT loop still work? >=20 It is expected that TDX-VMM lauchs all CPUs to the ResetVector(0xfffffff0).= After reset, all CPUs run the same initialization code (protected mode -> = long mode) until Sec Entrypoint. (see slides 22) After that APs spin at TdMailBox waiting for the commands (from BSP). Befor= e jumping to DXE phase, TdMailBox will be relocated to a new address which = is recorded in MADT table. APs then are waked up by BSP and spin at that ne= w TdMailbox and wait for command.=20 After exiting firmware, APs are spinning and waiting for OS to wake them up= . OS send the wake up command to the TdMailbox by reading the MADT table. > (8) "I/O, MMIO, MSR accesses are different" -- those are implemented by > low-level libraries in edk2; how can they be configured dynamically? I will add more description of the basic IoLib in next version design slide= s. Simply say we probe Td or Non-Td in run-time and then call the correspondin= g IO operation.=20 UINT8 EFIAPI MmioRead8 ( IN UINTN Address ) { UINT8 Value; if (IsTdGuest ()) { Value =3D TdMmioRead8 (Address); return Value; } MemoryFence (); Value =3D *(volatile UINT8*)Address; MemoryFence (); return Value; } >=20 > ... Back from slide 53: I'll comment on slide 53 separately; ignore this. >=20 >=20 > *** Slide 11 -- TDVF Image (1) >=20 > (9) CFV -- Configuration Firmware Volume (VarStore.fdf.inc), containing S= B > keys -- how is this firmware volume populated (at build time)? Is this a > hexdump? CFV is populated in post build. We can provide such python scripts to do th= e SB keys enrollment.=20 I will continue my comments in my next mail. [To be continued] Thanks!