From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by mx.groups.io with SMTP id smtpd.web12.19231.1622944991423358268 for ; Sat, 05 Jun 2021 19:03:12 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=kfrPVrIt; spf=pass (domain: intel.com, ip: 192.55.52.115, mailfrom: min.m.xu@intel.com) IronPort-SDR: v9zPRTEK8WCufpx2swelk8sZIsehvXESINX2QSYM5LHxW59NqmplBtOg0FoSR0BF8y2uaZFQu3 7cus3OwvW7RQ== X-IronPort-AV: E=McAfee;i="6200,9189,10006"; a="204286067" X-IronPort-AV: E=Sophos;i="5.83,252,1616482800"; d="scan'208";a="204286067" Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 Jun 2021 19:03:09 -0700 IronPort-SDR: PmL3f4BeuYO93f0pVZ1X7OpQy2ASmfQyYGH0Z0dp8ud8M9tPKS/J+uaptIs2ZJF6fmZ/iivHVp pPR5t7c1ySew== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.83,252,1616482800"; d="scan'208";a="439627537" Received: from orsmsx601.amr.corp.intel.com ([10.22.229.14]) by orsmga007.jf.intel.com with ESMTP; 05 Jun 2021 19:03:08 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX601.amr.corp.intel.com (10.22.229.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Sat, 5 Jun 2021 19:03:08 -0700 Received: from ORSEDG601.ED.cps.intel.com (10.7.248.6) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4 via Frontend Transport; Sat, 5 Jun 2021 19:03:08 -0700 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (104.47.66.40) by edgegateway.intel.com (134.134.137.102) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.4; Sat, 5 Jun 2021 19:03:07 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aMu/ZgfXxyIBGegmFt/kQwhJUMN75F4+w5F4q9n09MFT8BtKh1OhZN2ejvCwS06wWBzZM8aj+KERSKdVX97clocECjnn6lKY6dYdCVw0wy+3/h5zPPvWu6wRHwOzIVZe40DbFc0iUGOUgbPIPHtcNnwyNdua2x7nlrTWgjdYWFCmzPU094y9aqZBZMGfWlu2awH3KA/772nuRSvj1qvdol3bONiT4MkWphNoDc7TAna4fbznQ+QxHqAu9twI+iPAnU94ntnD9cuXORAzxOMlnBI+ZfQB7+8dsQT5DxbaoDbUelmt75Sd5SH2TqiZeW+WlS8x5tbGLq9zA4Vj1aSNpA== 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=lwRJspFvfATpkAzD0lkB9QhygQ7vp94m9CaS0rFlYyI=; b=Y1quoNsj5Pq2EAb28AG2ckttEvXwJFGUG2+2cWcHIgkBa9HxKR7hFBos8/YJA5S1+Rw4P8MXAgoNhnjO0UBmMwqpT7yE9uiAUTJdvLR0U9k2mqu48xa+3UhJegyg+T0ks/TzqlmbqA2Q0s9pCQTfLZX6DLnq9jrAUn2T9vR4LWYBGCsO8RpWauzXCmHV4qWE9fjgthzreqA2wv19asw0ClnJque+jAWbhWgN7Fvof/55wW2dXC/sv6kmaz89qahhDGEOIFrZ4lLjGf3LaPXurgv1Dyp/S4my3BTVGdur++J36fBt5Li6t984Zp3ZivR+UstGJDrdHufieYN+m8S71Q== 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=lwRJspFvfATpkAzD0lkB9QhygQ7vp94m9CaS0rFlYyI=; b=kfrPVrItlHi+8hWmtsLX8JeO/xGPS1P0luqsnCYBm6Y/0jFtnOs+gXD6VXwaOC3MxahLlcWP8PneKVU6gPR/4WXawpvEDgIQpa8jVZqU3UF/rCHF5JVx+U7pHlVGZonndWfUEtOhwHttYZGtAKnS8i0qKsVsR35R5Eglf7WA2JE= Received: from PH0PR11MB5064.namprd11.prod.outlook.com (2603:10b6:510:3b::15) by PH0PR11MB5078.namprd11.prod.outlook.com (2603:10b6:510:3e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4195.21; Sun, 6 Jun 2021 02:03:07 +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.4195.029; Sun, 6 Jun 2021 02:03:07 +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: AddYf4DUPECuZ9ubQaOwhq0M0PgYbAAE6sKAAHdVguA= Date: Sun, 6 Jun 2021 02:03:06 +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: [101.229.202.75] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ac23442f-9548-4c9f-94ec-08d9288f3a23 x-ms-traffictypediagnostic: PH0PR11MB5078: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Dr7Evf+5mKudzSf9gCAKBWWLutzKs1pqtHR1Vu5mhcj0pzjVKfgnIhGlflvUyf/0aaF+NITKkNDu3dK3lbmOEQeB5vbEvb4oPp57yRJYt3zcMrl4HXeJVEkkLfwA2IAUUJY2jOwQAsS0IK2+o4Q7iFqly0h1w1Co3qxPGKnE5S2HZoejOJUE+lGnn2uAgvnXw7fq88E9sQXQO7m5vMozrfUbxFSLdy7rFaUpow796lm/SyhqBvLjcUkCzJDM+lFmREbBUt2hgMYxzhaROcdMvq3R188+NdaLZUUlb1tbT5FkX+emR4pxHh4UpMn6B2BrFdJvdeV88tyxhzwYNqM9UVTw9+YAHXg6KZWC3dM4H9nBDvklhyKCe0isxqKY7ElWJn8dh8oJKz3VEpeIyNmRB8eL7svuqzeB9WOAwNnZYEcq8+2TksGIZNheRR/ZithyzvWCdKEl+0PN84my9YOi/cezJaxvZ7PDkDfQYpUsmS01u2ek2IDSXZG+6lowit/WqlIMZk/MDAFE1gCG1Y+Pzqx0Z8qDvx7oukdodhCX+9+8tB5rmikam6Un7694jcD3Uuzu0F0qwRsHF6noDHynPVPB7b6ujw/+dJ/YQAIZp7i2D8iknx6aVSLimyvHLKjD44ALa2SR7KOoyCg0OYcc/RTaf5C/IaZLVq40+7u4VMJI6EDpx0Qq7O1ZT0B4qQgzC+eFPnxbP4AMKS6R9WUYMtm30d6FwBFWF14G+1/ZzGm4nF6XhcH8nGwxC9Iv6xygAZnyI+5hWmiuBCcXieY6yw== 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:(346002)(366004)(39860400002)(376002)(396003)(136003)(7416002)(19627235002)(8936002)(478600001)(8676002)(7696005)(966005)(26005)(6506007)(2906002)(122000001)(71200400001)(53546011)(38100700002)(4326008)(54906003)(76116006)(9686003)(64756008)(66556008)(66446008)(110136005)(66476007)(5660300002)(66946007)(83380400001)(86362001)(316002)(52536014)(55016002)(33656002)(186003);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?xPX0HbnvQYue/gl3Zza1DXOEx0cFfk9AA9RZ+2VHG2QwyxNDGH87cSqyFybn?= =?us-ascii?Q?3V5/ha15KT/V9PrpjglX9EQjJGHE1hX5yvNCYIgf9F6ztZBIlrqntdpo91or?= =?us-ascii?Q?Fe39orH/GoTqNydvke/AiYwZ5bATwLzZ4RGcxKEAfOimwkRP2zfzhWSTIqlO?= =?us-ascii?Q?Y3PSsxwBApIJkcRcOECigwPdeSvZI3Y03X70pdFJmRPOn10jt6OizT4ZTT1T?= =?us-ascii?Q?wXklf9jQ+eS3gEqFsfv8RM/TqfMVs9HeNnyKcX/rBthns44BaorEfDu2+Bjz?= =?us-ascii?Q?T7XJ6vbRlUjUxQO1xPTiiTxHLUKVbdaktTK4bwSG4zTG6/WPBpNXeyW2xZz8?= =?us-ascii?Q?It5hd3gzc9Xc2og1vRRDQIx0cUMnSD8feYyk9i+djsmEkyfYb0bV5PLnBAqR?= =?us-ascii?Q?ldxI0UgzLIsDPRYwmkf3A86t+0OmB+pE6J50RONTbTxb5Ir9qr50dw3GfW84?= =?us-ascii?Q?RHTeJbj5BEzJL733V2wiL+XWz7/k3z6UPlk4M3kM/lEcUtauUM75WR0bRzU6?= =?us-ascii?Q?+7ADNKLiFcMomTrE31PRj+BF2L07HTdWVN62dF69PclEk8+XqkNdNljTg6hK?= =?us-ascii?Q?Wh3faiuENDVIEIJvWzeijsLYFT1yGV9tl4UImITkWSqWlL7G3QcX32R3oFxe?= =?us-ascii?Q?hqPsvJ6fkGcRuPEVS7XMWU/fTlhzT+YNMSohXoCl+0v0UVTIeWAMcwr+FlyI?= =?us-ascii?Q?9gHcH7wSQrHxfE3ixYenH3yuqoVlx9h3SGrj2DX/JnvqntQBfZLKu1Ifo6uw?= =?us-ascii?Q?lSenWbh6b6TKV6Ye8nJ4TsEvyoeOxmyhTCdqgAXQQQSaWQFNY4XHIEh6lPXV?= =?us-ascii?Q?pvrF98kH/PG845uvxh91liDyIIko+ofIWY4dubLiLk7MWCiP/E/tTpCNGAbm?= =?us-ascii?Q?9P+CYFb3ik311mz1DkXqEw9q8EmUrd/0Y7cGdaWEfoh+vsj0YEaUNDFPTU19?= =?us-ascii?Q?hX1KLGs5/2GrTZabFOdUrVbusVtHkChbsT/nHxE28PQEJnUv5V00brfSiate?= =?us-ascii?Q?A8DTYrgrKymssJ1fz/xz+iwTZHIAMOfPwATTWBuoymKHqBv2UZ9y+WUmJUJo?= =?us-ascii?Q?JFwpTuOJz0lgjdKaZaUnz5QxgQnfa9PjeiNnwX+G1oJvyaCcXg0372QjI27X?= =?us-ascii?Q?lebu5M7/0jqcJCW+lQS7nyfP00qGqlMVCJIQx8NmC8GER5PPzOulhXsFXFgl?= =?us-ascii?Q?L1SPH+Yxir6Ez6lfHf26v2eOEuuFux5VzwWxmn/XKAcylsBJQEwSR8u83niF?= =?us-ascii?Q?E0Jg/D9HlrdIwKQpp5rz/g8ZsJLl/pXQ3RpuWTsh9LSQJZtAUEua+jNs2NH2?= =?us-ascii?Q?2turyseuO3aHDSkjhh3EySm+?= 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: ac23442f-9548-4c9f-94ec-08d9288f3a23 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jun 2021 02:03:06.8947 (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: JFxZNY+k4W1ChgvWCBbW260dV9yiSl0p4EpHKHpN0CXAds3Q+4cZK00qH9W2LxSevHdBfXZvT9jnaiSl17/Dxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5078 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 June 4, 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 Continue my comments from here. >=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? >=20 CFV is populated in post build. We can provide such python scripts to do th= e SB keys enrollment. > ... Back from slide 16: it seems like CFV is a raw hexdump indeed; how is= that > managed when keys change (at build time)? >=20 As I mentioned above, SB keys are enrolled in post build phase. We can prov= ide a python scripts to add/delete/append the keys. > (10) This slide (slide 11) basically describes an intrusive reorganizatio= n of > "OvmfPkgX64.fdf". I don't think I can agree to that. > While confidential computing is important, it is not relevant for many us= ers. > Even if we don't cause outright regressions for existent setups, the > maintenance cost of the traditional OVMF platform will skyrocket. >=20 > The big bunch of areas that SEV-ES introduced to MEMFD is already a big > complication. I'd feel much better if we could isolate all that to a dedi= cated > "remote attested boot" firmware platform, and not risk the functionality = and > maintenance of the traditional platform. I think this ties in with my com= ment > (1). Actually in our first version of TDVF, it is a separated dsc/fdf. But when = I try to implement the *one binary*, I have to figure out some way to put our mailbo= x/tdhob. I checked the OvmfPkgX64.fdf and mimics what SEV-ES does in MEMFD. I would wait for a conclusion of the *one binary* and then figure out how t= o handle the mailbox/tdhob. >=20 > For example, seeing a configuration firmware volume (CFV) with secure boo= t > keys embedded, in the "usual" FDF, will confuse lots of people, me includ= ed. > In the traditional OVMF use case, we use a different method: > namely OvmfPkg/EnrollDefaultKeys, for "priming" a variable store template= , > in the build environment. As I mentioned above, the SB keys are enrolled in post-build. The standard = build script: build -p OvmfPkg/OvmfPkgX64.dsc -a X64 -t GCC5 Its output is a standard OVMF image (with a clean CFV/VarStore) If the customers want the SB feature configured, it's up to them to enroll = the SB keys.=20 CFV is just a concept in TDVF. From the perspective of Standard OVMF, it is= still the VarStore. >=20 > Edk2 (and PI and UEFI) are definitely flexible enough for accommodating T= DX, > but the existent, traditional OVMF platforms are a bad fit. In my opinion= . >=20 >=20 > *** Slide 12: TDVF Image (2) >=20 > (11) "Page table should support both 4-level and 5-level page table" >=20 > As a general development strategy, I would suggest building TDX support i= n > small, well-isolated layers. 5-level paging is not enabled (has never bee= n > tested, to my knowledge) with OVMF on QEMU/KVM, regardless of > confidential computing, for starters. If 5-level paging is a strict requi= rement > for TDX, then it arguably needs to be implemented independently of TDX, a= t > first. So that the common edk2 architecture be at least testable on > QEMU/KVM with 5-level paging enabled. >=20 Yes, 5-level paging is a strict requirement for TDX.=20 I would wait for the conclusion of the *one binary*. >=20 > *** Slide 13: >=20 > (12) My comment is that the GUID-ed structure chain already starts at a f= ixed > GPA (the "AMD SEV option"). Ordering between GUID-ed structures is > irrelevant, so any TDX-specific structures should be eligible for appendi= ng to, > prepending to, or intermixing with, other (possibly > SEV-specific) structures. There need not be a separate entry point, just > different GUIDS. Yes, we prefer a TDX GUID in ResetVector. In that GUID there is a offset wh= ich points to the actual TDX Metadata blob. >=20 > (13) Regarding "4G-0x20[0x10] is OVMF AP reset vector (used in OVMF > implementation)" -- I think this is a typo: this "AP reset vector" is > *not* used in OVMF. To my knowledge, it is a vestige from the UefiCpuPkg > reset vector. In OVMF, APs are booted via MpInitLib (in multiple firmware > phases), using INIT-SIPI-SIPI, and the reset vector for the APs, posited > through those IPIs, is prepared in low RAM. >=20 Thanks Laszlo for explanation.=20 >=20 > *** Slides 14 through 16: >=20 > I consider these TDVF firmware image internals, implementation details > -- do whatever you need to do, just don't interfere with existing platfor= ms / > use cases. See my comment (10) above. >=20 Sure. All the TDVF changes will not interfere with existing platfomrs/use = cases. >=20 > *** Slides 17-21: >=20 > (14) Again, a very big difference from traditional OVMF: APs never enter = SEC > in traditional OVMF. I assume this new functionality is part of TdxStartu= pLib > (from slide 18) -- will there be a Null instance of that? Yes, there is a NULL instance of TdxStartupLib. >=20 > Last week I posted a 43-part patch series to edk2-devel, for separating o= ut > the dynamic Xen enlightenments from the IA32, IA32X64, X64 platforms, in > favor of the dedicated OvmfXen platform. TDX seems to bring in > incomparably more complications than Xen, and the OvmfPkg maintainers > have found even the Xen complications troublesome in the long term. >=20 > If I had had access to all this information when we first discussed "one > binary" on the mailing list, I'd have never agreed to "one binary". I'm O= K with > attempting one firmware binary for "confidential computing", but that "on= e > platform" cannot be "OvmfPkgX64.dsc". >=20 > Even if I make a comparison with just the "technology" (not the remotely- > attested deployment) of SEV and SEV-ES, as it is included in > "OvmfPkgX64.dsc", TDX is hugely more complicated and intrusive than that. > SEV proved possible to integrate into existing modules, into the existing= boot > flow, maybe through the addition of some new drivers (such as a new > IOMMU protocol implementation, and some "clever" depexes). But we never > had to restructure the FD layout, eliminate whole firmware phases, or thi= nk > about multiprocessing in the reset vector or the SEC phase. >=20 > In order to bring an example from the ARM world, please note that platfor= ms > that use a PEI phase, and platforms that don't, are distinct platforms. I= n > ArmVirtPkg, two examples are ArmVirtQemu and ArmVirtQemuKernel. The > latter does not include the PEI Core. >=20 Thanks Laszlo. I will check the example from the ARM world. >=20 > *** Slides 22 through 34: >=20 > (15) All these extra tasks and complications are perfectly fine, as long = as they > exist peacefully *separately* from the traditional ("legacy") OVMF platfo= rms. >=20 > Honestly, in the virtual world, picking your firmware binary is easy. > The approach here reminds me of a physical firmware binary that includes > everything possible from "edk2-platforms/Features/Intel", just so it can = be > deployed to any physical board imaginable. That's not how Intel builds > physical firmware, right? We have "edk2-platforms/Platform/Intel" > and "edk2-platforms/Silicon/Intel" with many-many separate DSC files. >=20 I will continue my comments in my next mail.=20 Thanks! Min