From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mx.groups.io with SMTP id smtpd.web11.61909.1638844090173329236 for ; Mon, 06 Dec 2021 18:28:10 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@intel.onmicrosoft.com header.s=selector2-intel-onmicrosoft-com header.b=GnkoXEGb; spf=pass (domain: intel.com, ip: 134.134.136.65, mailfrom: jiewen.yao@intel.com) X-IronPort-AV: E=McAfee;i="6200,9189,10190"; a="237415387" X-IronPort-AV: E=Sophos;i="5.87,293,1631602800"; d="scan'208";a="237415387" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Dec 2021 18:28:08 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.87,293,1631602800"; d="scan'208";a="657516674" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by fmsmga001.fm.intel.com with ESMTP; 06 Dec 2021 18:28:08 -0800 Received: from fmsmsx607.amr.corp.intel.com (10.18.126.87) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 6 Dec 2021 18:28:08 -0800 Received: from fmsmsx601.amr.corp.intel.com (10.18.126.81) by fmsmsx607.amr.corp.intel.com (10.18.126.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 6 Dec 2021 18:28:07 -0800 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) 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 via Frontend Transport; Mon, 6 Dec 2021 18:28:07 -0800 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.169) 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.2308.20; Mon, 6 Dec 2021 18:28:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HxnPA4VpEniBwoMYJh4lX51zvLAvWdmqseemOGn+9Um4/Xk33wSB9Du7ns58kyiuIIeCEe4nkj9Y+3xtwvWz06KZwclF+7WqMEmbgYs0GTr3U9ePpU+wX8jiuLXuONtAJy8HLOHtRyF8CkxUcJe8MMYra9XDk7NGMjs8v2Q+gHjtfxdtCEw5nZpQqLfYCjph2LLRMQ5UrVry2/qlvCPZW991cIu7/w0bE8SPOR7e75qtPrVGneTBmJNpIuK0sv+15yBdB6VHAY61blPUdHMYQEEfwbwm++oXdmRXZuoClRcUQqQdhgykToRL39JJoyXEuJKjzkSk+TrR2KpVc9FY9A== 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=KIiW/6Np3z1eD5brc3+pT8xdIWhmbiXTPqevgCA3tKY=; b=ZrF1EwwSVmwFE9FznrXmbA5aJ823gGGGN62tz8Jlg8BNYJHe4fNKdKUoJLxArBNphIyd51mykQ5qsdRjAKoZhGipAhaSSdx9/ubB/UVTBvysZfP0VR2VcVxEiP5OCgELlq+K+hz7CK/XIGpNer8iOl/DHTlUPYOfe/tSgdKSI8/2HTXRvQpp3pn9zkjPbf1dkSeRmBhBnMMUSLzS3JoB/piCTL4y5pnDHVg97l8UhC4esxyDKj0jJrl8Za1Fl8Rlb4t8UtHFZnEDzKoQZfl6OoIxW3jx7sYwV0OtJC5CgmJtOJQQs2v+TrVn9Kp6XJGf8wGlNX19xl/MCtCAuFZlPw== 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=KIiW/6Np3z1eD5brc3+pT8xdIWhmbiXTPqevgCA3tKY=; b=GnkoXEGbWT0N72gxRWYBZWxNM05K7QRXtROErHysliZsrUBv6zjbcymCblzwGcwKA7qlyt/LcApU6Ightb5ITp++ZHRmhPihi7OccBCfwUzOp2qZTlwgHKCEaIDB1c0x0WiOqsS7bodeTdHRERAbzLZMhFgeCXGW7KpaEh1CLpk= Received: from MW4PR11MB5872.namprd11.prod.outlook.com (2603:10b6:303:169::14) by CO1PR11MB4852.namprd11.prod.outlook.com (2603:10b6:303:9f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Tue, 7 Dec 2021 02:28:06 +0000 Received: from MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::1d07:d296:b2c7:7114]) by MW4PR11MB5872.namprd11.prod.outlook.com ([fe80::1d07:d296:b2c7:7114%6]) with mapi id 15.20.4755.019; Tue, 7 Dec 2021 02:28:06 +0000 From: "Yao, Jiewen" To: "kraxel@redhat.com" 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 Thread-Topic: [edk2-devel] [PATCH V3 15/29] OvmfPkg: Update SecEntry.nasm to support Tdx Thread-Index: AQHX2uMZH+dNhguCw0OBghbxJplRDawH11AAgAEwN+CAAfIoAIAAvv7AgAVfi4CAAAXBAIAAGIUAgAAC0naAAAQtAIAABTlIgAAHrQCAAKQIkIAAcbwAgAArxNCAAC6GgIAABxjAgAAB1wCAAABGQIABNH6AgAESSSCACLXkAIABflnwgAZuxoCAALoP0A== Date: Tue, 7 Dec 2021 02:28:05 +0000 Message-ID: References: <20211124081204.ortxlgwgp2c5dlhw@sirius.home.kraxel.org> <5d39c546fe66fc945e9687f187ed9892b6a6a00c.camel@linux.ibm.com> <20211125083219.uiqbg7fsoervmdkq@sirius.home.kraxel.org> <20211201135506.bwxpo5h4fr5lcbni@sirius.home.kraxel.org> <20211206145737.e3bh6fl65j6qw62f@sirius.home.kraxel.org> In-Reply-To: <20211206145737.e3bh6fl65j6qw62f@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: 383ecaaa-5043-4a0b-15d7-08d9b92933b6 x-ms-traffictypediagnostic: CO1PR11MB4852:EE_ 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: 4MDmeDZqjydD1cPehM66GpUGE2L7YQPbdKt2dwz6ZCujUCOK1M9AUZwup2ST0jf87Xmb0YwwvvTgBsnrx0us7nkB8x/9NNgS44EQPIngKQGtz5Y6q7chxI9s9TXiaVvdboHo2nD2rwc0DjeGLk73W9JYaOsiiyAq5yZYc62um5y/sjfPuBPqwCnRG6rcrAMfGc/BMGshL4yeLc7liNivjTggQUgXErFy90oqBoe/paHbmOHUleinO8dxzBecDzQ4Bl3uyvARirS7M4CZTnr7vmaMypN2SaI0bF9Ao7sU9pU8AOQmQtBvsZa7+J5TP8mffFuKYCOBWpo4r/10JlWlLmLpk5GJDg+i/Z840jrC0kCJxbSlAgmUTlZOAj439Nsq2NoIQL348f0VlTz/E3NYDNFsnkxY5TblVMzNTkcC5rY+cX0c6cPAAmIQ10n4oaekAX5UY2VEbT7gAdhq8SIjiFrw7fXdcSuzk5P4hrCo+T4SlQojSlr6oVlVo1ITYmS3iQiDgNMvNGLV+WYu3yfXVi3XliYi1gcV7PE64jScWK4SO8zw7n6qR6zSRVTh8yS3ogjIQflkC+9VCe9WtBitlkLFac+b3/bPC6fW+ei2zC7v76B2AiL1bvc/5kyYeG2WJRaeAFGtOULRHlUMqWd4gYYewVyiKpS/bUxBQ3vB9tMXXe/h3zHnrtHMJIHtzDrXVe008fnFttyhzVVmOWjugw== 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)(8676002)(82960400001)(5660300002)(6916009)(52536014)(54906003)(33656002)(66946007)(64756008)(66446008)(55016003)(66476007)(66556008)(86362001)(83380400001)(26005)(38070700005)(7696005)(186003)(38100700002)(122000001)(8936002)(15650500001)(2906002)(76116006)(71200400001)(9686003)(4326008)(316002)(6506007)(53546011)(508600001);DIR:OUT;SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?W/cQcMpzQpvX9RR7dAzXoYBbfllvgZVIaXkNehLK5/ap+9wRAZXsJ6xp0rfE?= =?us-ascii?Q?ipOuBdLM5LLm7vReIJM+T4TfjBYNAWnH+Ui8Hc1L1Rmur2ZmXkCGCTjSy+02?= =?us-ascii?Q?GennLoPaYTyqZRIReYV1ByaSshMX807s7viD8z/YeoQDJ0YNDBCH0ociG1Tt?= =?us-ascii?Q?ViKP/pl+gdDtJnYjY02vJcROQTYZ+sIjMAxPrqJsrrk8+/7o87dgjWF9pvsc?= =?us-ascii?Q?VkbqzAtdXhBECWf/IVtcxWNMYrZHdfvyN+zm+kUk9E3T5gcdWw0AyI45jroa?= =?us-ascii?Q?nX6zPaYs+XGzQuCmFaO9HqkWJu2Wp7de3bpnS2WKnOA3d2X3h7dUnw2V9hYU?= =?us-ascii?Q?MZJQirgF/lV8T+7quvy4yjuYegYjttlsbWlVo/fJgedxMx0FHpy+Ix3FrOXm?= =?us-ascii?Q?u7Vp4QjdO4VolS4ROEc7mOf7pDtQzXWezsZiiv2i0yRRdTEcugsy4QFWuris?= =?us-ascii?Q?n2LdjXO2G1oEfJjlwzZ24u2wYkHRolJtOupyzBp3mFAKEMqnHzyrfHtCDcIp?= =?us-ascii?Q?2wQx1XadzTpcySfUsaBdyYz+bT4J9cZPr50Gw/EeHEC8/niN3N+Y6dPKGLKw?= =?us-ascii?Q?4z+3HvPhr4ZM8zuNKuNgIOj5JBkoDI6gEcy1oJLgYE6t+AYEW0nbQX+qDX8U?= =?us-ascii?Q?XVlBTi3NIvbFLRm/KEUOXMdDSvFpmnQ0UYbd2MBl5jUsn1gcKDMIBCqnlT5M?= =?us-ascii?Q?pl/6CEt1tt6k7j5HdEJURGZZQCOfKoPzAx1cpdy3HuIPKppBAxAZtjZ+kJsq?= =?us-ascii?Q?gCUg4N07TsEK5K1ynbbCPcCpi8Bmm4TTbMli7PicU9hJLQFrR1KtXolw2qdt?= =?us-ascii?Q?MOqUpCx/PD/sgGXMtVluWqwlUnmEMI0n7bj7OZNqnSFUs+k2SJPeTh00JaIH?= =?us-ascii?Q?rW/jkyGBtQO8UA77oJSsVw58/+mjFbXSyZPbOH1+4FsqgDhUkfYnlMdkca8u?= =?us-ascii?Q?vV/v3NxJF6vOA6qI0/fwQyE/zYJpZ835JplYHBazExB8dxPhWdphVyZOeAWN?= =?us-ascii?Q?IYC+cI09jk+dYd512YnG3UM82xi+KO/zyRz1FhutrP3FvPKG2WP2YmtFyvzP?= =?us-ascii?Q?6C9mZBgEALyxZXN5f41953BqyQoM5EijDCFH4IPOsKvKR5ygqjaHWSNgfpJ3?= =?us-ascii?Q?NWJTIl+hn26E3LRD44zKt9XNV92ZwNZhVcTs8XyBb6XVpvBmyxoxW3YERLGL?= =?us-ascii?Q?zyKXg9EZ/Ld0IraY8jHl4RdYHz8d1zM0YKBD1VNdQkXsgO0lNHZDa1Zkkr0d?= =?us-ascii?Q?XHB48/1pzbP/bpCWzYciDMnLyYlpevzAOyfylmzGUvOfEWYamMmtlzWlkPT0?= =?us-ascii?Q?Flk6/Ohw2wzNB/6GkHmIGJchEyW8+hbNbPxi6xDlGJb9YkfjTnvMUlsJgG27?= =?us-ascii?Q?x2dyYuLVBojhKfuNPX03bd+lyWqnj1ZB6MFhj0tKDAaYAL2yZWblPkRAAqj8?= =?us-ascii?Q?ZQKEnMnLfkhDJcypLF8WU3u0irFA9qmlnfU2MYbQUreVePa/GFdXszDEmBzA?= =?us-ascii?Q?VLRFzQaaBa4ImwBTPVg3DXruqDLjbKhzWh3kme+j+rPhMD/10GFCx7ToGycz?= =?us-ascii?Q?gy0T/uaD33MCTLF2Bvi5Xmf16Sw9gM989S7aen950ebk67/Seh/Yvxxkim5W?= =?us-ascii?Q?qpofGLFlkTbhQjwpGuVK0hk=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: 383ecaaa-5043-4a0b-15d7-08d9b92933b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2021 02:28:05.9983 (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: um3+P/1U28zwp3n5NYHWeD+k7iYLwn8BqLnNsjS2DS4MkMWaYkJyW9uYS1qw1y44KtIp554Dow/hhwprqbeH2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4852 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: kraxel@redhat.com > Sent: Monday, December 6, 2021 10:58 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 > > [Jiewen] Again, I feel lost. > > > > Would you please clarify what is your purpose for this discussion? > > > > Yes, Security related stuff in PEI, that is not a problem. For > > example, we moved flash lock from DXE to PEI. (I already describe that > > in my previous email.) >=20 > Well, you tried to make the point that PEI shouldn't do anything beyond > memory initialization. Which might have been correct for the initial > design, but meanwhile it is not true any more. [Jiewen] No, I am not making this point. My point is : It is legal to move a feature from PEI to DXE. My understanding is that: you are making point - "It is problematic that mo= ving a feature from PEI to DXE". I take "feature" as "any generic feature". I accept the statement that "It *may* be problematic that moving a *specifi= c (such as security)* feature from PEI to DXE". But I disagree the general statement that moving any feature from PEI to DX= E will cause problem. For PEI, my point is 1) According to PI spec, PEI is minimal so it is legal to move feature from= PEI to DXE. 2) We do see some examples that we move from DXE to PEI, but that is case b= y case. It does not mean you cannot move feature from PEI to DXE. >=20 > > The key is *privilege*. If you don't need PEI privilege, you don't need= move to > PEI. >=20 > > 2) "SMM" support is in DXE today. What do you mean SMM support in PEI ? >=20 > ovmf has a pei module for smm support (see > OvmfPkg/SmmAccess/SmmAccessPei.inf). [Jiewen] The SmmAccessPei is for S3 resume. It is already documented to PI = spec. I don't see anything wrong here. > > But I don't see how the examples support your statement on "exposure". >=20 > Well, lets stick to the flash lock example. Moving it from DXE to PEI > makes it less exposed. It'll run before DXE starts processing > externally controlled input (efi vars, kbd input, disk reads, option > roms, ...). So trying trick it into not actually locking the flash is > much harder. [Jiewen] I am tired on using word "exposure". You gave the definition that = "exposure =3D=3D external interface". And your statement is that we should move "feature" to the component with l= ess exposure. - I take "feature" as "any generic feature". In my opinion, less exposure !=3D high privilege. There might be some relat= ionship. A high privilege module may have less exposure usually. However, t= he privilege is *cause*, less exposure is *consequence*. Not verse versa. W= e made judgement based upon privilege, not the exposure. I accept the statement that "We should move a *security* feature to compone= nt with *high privilege*". But I disagree the general statement that we should moving any feature to l= ess exposure. I give a counter example - SMM. SMM has less external interface, but we can= not move "any generic feature" to SMM. >=20 > Or, to put it into another way, it reduces the attack surface for the > code with higher privilege. >=20 > (it's of course also need to make sure you can't unlock flash with a > suspend-resume cycle). >=20 > > > Well, I want focus on how all this will look like long-term, i.e. onc= e > > > we have lazy accept implemented. I don't think it makes sense to put > > > much effort into optimizing a workflow which will only be temporary > > > anyway. > > > > [Jiewen] This is the long-term solution. > > Lazy accept and MP accept are two required feature. > > > > "Lazy accept" just mean you can do things later, but you still need do = it. > > "MP accept" means you can do things much quicker. > > > > I don't think we can remove MP accept just because we have lazy accept. >=20 > I don't want remove it. But with lazy accept you have more options to > implement it. No need to go for assembler code in SEC, you can use MP > service with standard C code in PEI or DXE. >=20 > > [Jiewen] the "barely enough memory" is 64M and it takes long time to > > accept if you don't use MP. >=20 > If I remember the numbers correctly (roughly 4 seconds for 2G on a > single processor) that "long time" would be roughly 12 ms for 64M. [Jiewen] OK, I talked with Min again. 12ms is not right data today. We have bigger number, but I cannot share the data according to legal reaso= n. But I agree with your statement that, if the data is small enough, then we = don't need MP in sec. I propose this way: 1) In first patch, we drop MP in SEC. 2) We can revisit if it is really needed later, when the TDX platform is ab= out to launch. I believe we will have more precise data at that moment. >=20 > > > That is the point where you start re-inventing the wheel though. > > > You add logic to distribute memory acceptance jobs to the APs. > > > I'd suggest to add full MP service support to TDX (probably also usin= g > > > the mailbox), then use MP service to distribute memory acceptance job= s > > > to the APs. I think you will need that anyway for lazy accept, to do > > > parallel accept in DXE phase. > > >=20 > > [Jiewen] I think I have stated it clearly that this is due to TDX > > architecture, we have to rendezvous all APs in SEC. So the MP code > > SEC is unavoidable. We have to reinvent the wheel in some way. >=20 > Well, adding TDX rendezvous support isn't re-inventing the wheel, you > surely need that, no question. >=20 > But then you go create your own job scheduler (also accept job > implementation), all in assembler, instead of using standard edk2 MP > services with more readable C code. *That* is where you re-invent the > wheel. >=20 > > > > 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, w= hich is > a > > > big number. > > > > > > What is all this memory needed for? > > > > [Jiewen] These are initial memory for PEI Core and DXE Core to initiali= ze the > content. > > If you don't have initial memory, the core will fail. >=20 > Where does the 50% increase for GPAW=3D52 comes from? [Jiewen] Yes, this is about page table. The reason is that UEFI spec requires you to map all memory. You have to cr= eate page table for all. >=20 > take care, > Gerd