From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by mx.groups.io with SMTP id smtpd.web10.21061.1637908151963206387 for ; Thu, 25 Nov 2021 22:29:12 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=JrK2jyqM; spf=pass (domain: intel.com, ip: 192.55.52.43, mailfrom: jiewen.yao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10179"; a="321851312" X-IronPort-AV: E=Sophos;i="5.87,265,1631602800"; d="scan'208";a="321851312" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Nov 2021 22:29:11 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,265,1631602800"; d="scan'208";a="592196799" Received: from fmsmsx601.amr.corp.intel.com ([10.18.126.81]) by FMSMGA003.fm.intel.com with ESMTP; 25 Nov 2021 22:29:11 -0800 Received: from fmsmsx612.amr.corp.intel.com (10.18.126.92) 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.2308.20; Thu, 25 Nov 2021 22:29:10 -0800 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx612.amr.corp.intel.com (10.18.126.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Thu, 25 Nov 2021 22:29:10 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Thu, 25 Nov 2021 22:29:10 -0800 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (104.47.58.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.12; Thu, 25 Nov 2021 22:29:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WBWnRIlbve4Ydk8FOSurjEXPTwJqN+xaUKejeVILmGE8g1TlKyPtF3IB18NRyM+H5CRKURqAS+h5c1hJesd4XTLTLIsXqOgAlJc9RvusNg4bLOGVf6QoQVsOPbXP18AlG6mSmlBuvb7yEDyLji+JKtCV3aalD9J12AOtk6nb5P1NDtWFXEPd7OCNsyq9g/QpTVIUYZZJOhme/XrnxrbRmwyCnyl5rH30VZ3SeInbECFYsnCDXwI/qJPeDmfnM7mxQ1w4GJ2ubEfNczt7HT01J19XNzG2qYqjJMM8QY+UnOkXEy2OjDxr9sn5QhjGRQ0gcmuli+9AJptmaRi4j4fjOQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=xGzN+NL5q2X9ygQTXPH5jG24VWMNas/xVgrT78yBofI=; b=VeYxEubYD0wVbLWzjz+VSmCWdQd3daqFuASzy8+dBzYwJVkbF/GzDSwqm901QnX9pPuyX4vpgVhnlSXAWhZtCbn+DALuZ999xYBeajbYwV7/sbhyAX7Iwdxja1Bqx5k8PVKuO6Iu0wEwq5JyT5/V+TITl3FkwvmjAACuUYz89uatu/fHcHgjOY+ZkzMKMJF5mF/BTgIVFJfCJes5MH2ebpEoMQN8k7xJ2V4SW65M0b1Q6awv/Af3aCtDa+FT/eoRC9rFKVa9bK55vFYW3om+IaIGRYeWTnpIbPDftSTZLJYMRIy06bbW7YTP3sPgHhdKhTC63l0D4/sHTuZ+QJQEzA== 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=xGzN+NL5q2X9ygQTXPH5jG24VWMNas/xVgrT78yBofI=; b=JrK2jyqMWRKTNxgzxM9UZUHE/8nXRiZ6Qcnh/eyu2HZ/lZLRrKVJ2eM3cFD5IaDBp558RsXAQgoPajSPUCSC/l46Cfd70jMiHtAkyS7829d4B5+5IUctiHd5KtkmJzRCJQmTi/0/TzUMIpm7Hep8Jy53RgHNGq+BGoHbdtz/3uQ= Received: from MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) by MW5PR11MB5857.namprd11.prod.outlook.com (2603:10b6:303:19d::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.23; Fri, 26 Nov 2021 06:29:02 +0000 Received: from MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::1d07:d296:b2c7:7114]) by MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::1d07:d296:b2c7:7114%8]) with mapi id 15.20.4669.016; Fri, 26 Nov 2021 06:29:01 +0000 From: "Yao, Jiewen" To: "devel@edk2.groups.io" , "kraxel@redhat.com" CC: "jejb@linux.ibm.com" , "Xu, Min M" , Ard Biesheuvel , "Justen, Jordan L" , Brijesh Singh , Erdem Aktas , Tom Lendacky Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Thread-Topic: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Thread-Index: AQHX2uMZH+dNhguCw0OBghbxJplRDawH11AAgAEwN+CAAfIoAIAAvv7AgAVfi4CAAAXBAIAAGIUAgAAC0naAAAQtAIAABTlIgAAHrQCAAKQIkIAAcbwAgAArxNCAAC6GgIAABxjAgAAB1wCAAABGQIABNH6AgAESSSA= Date: Fri, 26 Nov 2021 06:29:01 +0000 Message-ID: References: <1DF0C062-BF78-44E2-BE96-2C8727C36845@intel.com> <5ec6897681e46fe181193651164f0f17d5d1205d.camel@linux.ibm.com> <20211124081204.ortxlgwgp2c5dlhw@sirius.home.kraxel.org> <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> In-Reply-To: <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.6.200.16 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 694c8a21-880e-4fd2-0d18-08d9b0a6097d x-ms-traffictypediagnostic: MW5PR11MB5857: x-ld-processed: 46c98d88-e344-4ed4-8496-4ed7712e255d,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ciCFOkiEgbtBRPI6/S1htKhuikjpa3dO9h2zK5pbYbvqR2gYJwuN1DLOkgwuSB8kQoZp54FXy1Leh8ROF3l6Rkl7gP0fUpawa9kavMa4VPFQPc1ZdQEp+/UdD6m8m91l+C1KCJE44YrUkThhLQ3+noyFABzK5fuujNy5uqzIHLvQgb6fzN/RAvtLTZDBLuji6MqtgLTgGsx48qSQfPLnJoxcoLPZ2uj4e9Xjq7UOnCaxG6IcWgguJRbn02Zc0Dy8XMglJ/ExhRN422uJ70/YPbfDGXuRFGL7maYxVDRL7CW2JHflvV8BV/mXeWIrCb5l0Mh6CapBzWZBkJ0UbrwmAusUgrj7swQYLEQfclROnbNMWI9xKQiHJd+nToDlh1s+jgrCac4vTilChbYZjJGhi/hJZWaDPmxpkvObDBTThJ4Qv0UxqLLvBsVyk64GMLUtGASJOUT+YV3vm4NXueCBrAvy24JoOM5IpY8R6YnNGg6rJs+RwSttcV0jF5di9YtxBtUzTCSySTIzaZVhNunEmIBvCqk7O2/55wxAtgqbc85degNl2Rk4Zh/B+bpJaE9PV4Mh8noKDSGl7zxW8e5SZwfSfCA4J8iXwytTTW36Hu1v6ztFpmI0XIh1wJWkU2Z4zFVYdul8kcA7i8G4WRDkHdIU6MLEtlFcojWpO6WFT5PnHqr3bR0bjyXfY4s0v5M7rhZ1/mbApy3NX/gCmTSgc5i+HFCTFjjEKNMCmzvTCI8T7B1o70dPw2eWJ03eP+EzC3GGkAerl99CVGRc3x+P8fhINvtUzz6zN9k+yKQvuwq8NwXNG9cDm/PupEK1ZeiGzbV8/GLn92KtPOWL14LEy72RKWB3VxZAw2z4+I3udaoJ1o5TQhdln7bTZh8m6nR4 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW4PR11MB5872.namprd11.prod.outlook.com;PTR:;CAT:NONE;SFS:(366004)(54906003)(110136005)(186003)(82960400001)(9686003)(8676002)(966005)(5660300002)(316002)(8936002)(66946007)(66476007)(4326008)(2906002)(86362001)(122000001)(71200400001)(6506007)(15650500001)(66446008)(64756008)(66556008)(38100700002)(76116006)(55016003)(26005)(53546011)(52536014)(508600001)(38070700005)(7696005)(83380400001)(33656002);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?DNiIldXJMRErKHAzOex3coiAqbiwSnkJOrgSBQuYq/aVeSukC7YLzXOIlCAU?= =?us-ascii?Q?Oi+ZcCa2p6DLqs0ctq0+pjdDCYmN2c7bLAYwm0IuYVsDtqW+eOlqy54OBr22?= =?us-ascii?Q?48A42igrn8bWoV3m4goXQv9jbOYZ1pJ5lzhGz2RvJvLylG58DGdKG34iu4ON?= =?us-ascii?Q?H9nc49DVOjku18RG9sja8oi7cPBhlOD4hhaCxiAhiTdEXbD96QUfu7ekzoXe?= =?us-ascii?Q?SKm6ZR/vwXdctExRIVPVXtrj4tUI8elXOUDkRgLMjPej3YQ7F1egytAEsfP+?= =?us-ascii?Q?k8WJzdttLzEoioI9zwesT/26CC6nAnvRI9CZQSkEMHhV3+mZKqkgg0RTsye+?= =?us-ascii?Q?PpYfUuQnuZwW/iQcmaR6JVaNoYeY3cgs9WPdldEHthVJMXXPXnyI46z0K1Ig?= =?us-ascii?Q?aOG8J2CiLFKujIACYBfTft8qQ/7HbMpeZOxZNeexWkDlAYNGXeluszzgbJXD?= =?us-ascii?Q?0g52tOov0zMJCnuspocJKERm2TiVI7E4t9rCBivDEBZPBPXoafd/k3CZi7Kj?= =?us-ascii?Q?FdeQwooadsVLIPxuZMIFPlNDEl4Ff+sX5I7iNPk9B2REm/NF85VjqyTUBKLI?= =?us-ascii?Q?fVw2y4bdyJHdML1dCbs+8k2p+X8xuRn9YARbv9UrOimQjfhzHnmReK3BmrDr?= =?us-ascii?Q?BW+yy9hc27+JdZ3p2dPFwtDZoUGhOWqnfHh8Y7/Zw61nwwki88eOPbkrlJ0j?= =?us-ascii?Q?UQ2UmakvN4sOoAG94ycl+V2Th0Mp++QG65Vr76bi+YN5X/hp1ms2uhSHuADk?= =?us-ascii?Q?1/DTGh6vMdrg65Qu+VdxJAYMC/zfKOgZ3wO1LPqCuBxLQVv/p7b/NKO7SAYC?= =?us-ascii?Q?30nlzBqODGHNdtOX8DuH2RavgbuY/OtbVv7+EqjSSeAiaDc1P7fOaisW/WhK?= =?us-ascii?Q?DBdXH4HET3CZFrkr3M/KbgSsgX2IjkxwGI7BhWjkcd0zo4AQfsysk1uccW4S?= =?us-ascii?Q?/migPOOnkeVrnJH0WYhTs6A3/GNusD+5bHpGpo7BwU1hFufuwL4W+QstlusA?= =?us-ascii?Q?rHtxBShQ482tlzxc8evgAHuCKzalbkZv46mlig3g0IdSTa5UWzQg0UG6bcXb?= =?us-ascii?Q?I7qpTUKhPskw09YiR5nV25IcFCMh5oehvmWe8SGeqM8IqHg549BiUxy/IiL+?= =?us-ascii?Q?cgwCXRbQhyoxaaHxs+0Xez4supFLDnOLkSQ7CySQSGx4cLAijJxSPDoGwS5R?= =?us-ascii?Q?bM5XMYfMDJ7Na67MfKRlWNUQDg2RmpdILx09CHEHYNnoK/O7kLGXprvtKAg+?= =?us-ascii?Q?6N6DS8zS2YsClJCzY+6cIIvxw7rl7zqQouOG0ZvcX+T0cknhVpaRGiuC4KKC?= =?us-ascii?Q?ifpexEshdu+CM7ycDvo6eNKE0i8yVwTzapHihBHIetJsejdosO++no3sj2K1?= =?us-ascii?Q?rzQpT1WVKRArb1nFfGxRkSNoOLWgIbSEmUjuf4rmRbRBGB1+RwdXWiX1Ukzm?= =?us-ascii?Q?k6XIMgBzW42hFRhXfR5KLhbmep4B5t91J1Ef9ckUD0UuonqXr2SFhtZP18hV?= =?us-ascii?Q?D+INk05B6EQNNekn8HhVF7Sz+TqdXJ/Z3W76gcrz1QLr0KLe/hX/1ERfNQdX?= =?us-ascii?Q?cg9/KOy47PBx0MY/PfvE7BxPiaKENuT/FpnKrHlVLxlzOI+5bocCkOcsFgvK?= =?us-ascii?Q?wg=3D=3D?= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW4PR11MB5872.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 694c8a21-880e-4fd2-0d18-08d9b0a6097d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2021 06:29:01.8362 (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: W2GBOXzwyz03Rp7rCusMjzrkTVpiz/N2MR3x/V3IgOdctXWUHsmmXkOMpuyt2ZZdgw76bNB95dCmDWiFPf9DMQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW5PR11MB5857 Return-Path: jiewen.yao@intel.com X-OriginatorOrg: intel.com Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: devel@edk2.groups.io On Behalf Of Gerd > Hoffmann > Sent: Thursday, November 25, 2021 4:32 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; jejb@linux.ibm.com; Xu, Min M > ; Ard Biesheuvel ; Justen, > Jordan L ; Brijesh Singh ; > Erdem Aktas ; Tom Lendacky > > Subject: Re: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm = to > support Tdx >=20 > Hi, >=20 > > So, my judgement is by removing PEI, we can reduce the risk introduce > > by PEI Core + PEI Arch PEIM*. Reducing code =3D=3D Reducing Security Ri= sk. >=20 > Yes, PEI Core goes away. >=20 > No, PEI Arch PEIM (aka OvmfPkg/PlatformPei) wouldn't go away, you would > only move the code to SEC or DXE phase, the platform initialization has > to happen somewhere. [Jiewen] "Arch PEIM" refers to the PEIM required by the PEI Core. The "platform initialization" is FeatureX. It is something you have to do, = no mater you have PEI or non-PEI. > Moving code to DXE has its problems as outlines by James at length. [Jiewen] I don't think this statement is right, with assumption that your i= nterpretation for James' "exposure" is correct: "Exposure =3D=3D External I= nterface", and assumption that we are discussing general design principle. I give my reason below: 1) From architecture perspective. Please refer to PI specification 1.7A (https://uefi.org/sites/default/files= /resources/PI_Spec_1_7_A_final_May1.pdf) Section 2.1 - Introduction. "Philosophically, the PEI phase is intended to be the thinnest amount of co= de to achieve the ends listed above. As such, any more sophisticated algorithms or processing shou= ld be deferred to the DXE phase of execution." In history, the first EFI 1.02 implementation does not have PEI. PEI was added, just because the EFI need permanent RAM, while it is not TRU= E for the platform that requires DRAM init. If the DRAM init simple, then you don't PEI, because it can be done in SEC. PEI was invented, because the memory init becomes more and more complicated= and has more dependency. We want to have a better architecture to support = that. The *intention* of PEI is *only* to initialize the environment for the EFI= . That is why it is called as "Pre-EFI-initialization". This is very similar to the coreboot - ROM stage and RAM stage. (You can tr= eat PEI as ROM stage and DXE as RAM stage) PEI should only include memory init (biggest part) and related code. If you= don't have a strong reason to put a feature to PEI, then you had better to= put it to DXE, according to the architecture direction. 2) From security perspective. I am not convinced that "exposure (external interface)" is a good reason to= decide where the module should be. Thinking of this, if you prefer to put a module to the PEI because PEI has = *less* exposure, then PEI will have *more* exposure after that. If you move half of DXE features to PEI, then PEI has same exposure as DXE.= What benefit we can get? In EDKII, the general security guideline is that module location should be = based upon "privilege", following the security principle - "least privilege= ". If a module does not requires high privilege, then it should be put to lowe= r privilege location. In one of my email, I listed Trust Region (TR) concept. I copy them here ag= ain. (I added SEC/BDS/RT to them as well, because I miss that in the first email= ) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Second, in EDKII, we have similar concept - we call trust region (TR): 1) Recovery Trust Region (SEC, PEI) 2) Main Trust Region (DXE-before EndOfDxe) 3) MM Trust Region (SMM) 4) Boot Trust Region (DXE w/o CSM-after EndOfDxe, BDS) 5) Legacy Trust Region (DXE with CSM-after EndOfDxe, BDS) 6) OS Trust Region (OS Boot, RT) We use term "transition" to describe the domain jump. We don't use term "isolation". We use "isolation" where two co-existed RT cannot tamper each other. For example, MM trust region and Boot Trust Region are isolated. Actually, the only isolation example we have in BIOS is x86 SMM or ARM TrustZone. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For example, SMM has much smaller exposure (external interface) than DXE. But SMM has much higher privilege than DXE by design. However, it does not = make sense to move feature from DXE to SMM. All direction we have is to remove module from SMM to DXE, because the priv= ilege concern, regardless of the exposure. The SEC and PEI are almost same from TR perspective, they are in recovery T= R. Recovery TR has a little high privilege than Main TR, because there are som= e security LOCK activities happened in Recovery TR. For a specific case, PEI might be a better place. I agree. For example, fla= sh lock. I will definitely vote to put it to PEI. But in general, I don't see why moving feature from PEI to DXE becomes a pr= oblem, unless you can explain in detail what the "problem" is. > Moving code to SEC has its problems too. SEC is a much more restricted > environment. A direct consequence is that you have re-invented > multiprocessor job scheduling (using tdx mailbox) instead of using > standard mp service for parallel accept. I do not account that as > "reducing complexity". [Jiewen] OK. Let me explain multiprocessor related topic. I don't think we intent to "reduce" complexity in this area. I would say, i= t is same with or without PEI. TDX (also SEV) has special requirement to *accept* memory, before use it. T= he accepting is time consuming process. So the motivation is to use multiprocessor to accelerate the process. We have at least three architecture places to accept the memory - SEC, PEI = and DXE. A) Accept in SEC We need write multiprocessor code in SEC. This is already mandatory, even w= ithout accepting memory. The TDX architecture already changes the reset vector flow - ALL processors= jumps to the reset vector at same time. Having multiprocessor code in SEC is unavoidable. We have to do it, to rend= ez-vous APs and initialize mailbox. The code is written because of TDX architecture change, not because memory = accepting. So I won't treat it as a burden to add additional feature to mem= ory accept in SEC. At same time, the benefic to accept memory in SEC is significant, you can h= ave memory ready for use. I will explain later why that matters. B) Accept in PEI PEI has MP_PPI, that is TRUE. But the problem is: MP_PPI starts *later*. MP_PPI starts *after* the memory discovery (https://github.com/tianocore/ed= k2/blob/master/UefiCpuPkg/CpuMpPei/CpuMpPei.c#L706), which mean the process= will be: Step 1: TdxPeim accepts PEI required memory without MP_PPI Step 2: PlatformPei installs PEI required memory. Step 3: MP_PPI starts. Step 4: TdxPeim accepts additional memory with MP_PPI Now, you can see the benefit to accept PEI memory is not there. NOTE: PEI memory is ~64M if GPAW is 48, it is ~98M if GPAW is 52, which is = a big number. That mean, with the solution you proposed (use PEI MP_PPI), we will have tr= ouble on boot performance. C) Accept in DXE Almost same as PEI. You have to accept some memory before launch MP_SERVICE. Same boot performa= nce issue. As such, we conclude that doing memory accept in SEC is the best choice for= TDX architecture. You may argue that we re-invented is MP work in SEC. Right, but this is done because of TDX architecture. It is NOT related to config-A (w/ PEI) or config-B (w/o PEI). > And I've not yet seen the other changes you > have done for pei-less tdvf ... [Jiewen] That is because there is no many change. :-) Here is just some early code. 1) Platform Init In config-B, it is at https://github.com/tianocore/edk2-staging/blob/TDVF/O= vmfPkg/Library/TdvfPlatformLibQemu/Platform.c In config-A, it is at https://github.com/mxu9/edk2/blob/tdvf_wave2.v3/OvmfP= kg/PlatformPei/Platform.c 2) DXE hand off In config-B, it is at https://github.com/tianocore/edk2-staging/blob/TDVF/O= vmfPkg/Library/TdxStartupLib/DxeLoad.c In config-A, it is at https://github.com/tianocore/edk2/blob/master/MdeModu= lePkg/Core/DxeIplPeim/DxeLoad.c The reset should be almost same in from SEC/PEI perspective. I don't see a reason to carry whole PEI just to run platform init (~300 lin= e of code). For config-B, Min is working on it and doing clean up. You are welcome to provide feedback after we send out patch for config-B. > take care, > Gerd >=20 >=20 >=20 >=20 >=20