From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (NAM10-BN7-obe.outbound.protection.outlook.com [40.92.40.83]) by mx.groups.io with SMTP id smtpd.web11.1815.1686248829149199931 for ; Thu, 08 Jun 2023 11:27:09 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@outlook.com header.s=selector1 header.b=es2G7N5B; spf=pass (domain: outlook.com, ip: 40.92.40.83, mailfrom: spbrogan@outlook.com) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BtbX/fUvk+f7ljtZFkcK0rKcM1Aj6d0Jvsq6WHB/GID5lvavb4cuDIFGFode4+kPveFuEJy9f3Z9fHvFsEk4EA/2e4ohidQbLgtwLDhXUEz/GJfiuPg/F0GwBRlfxECsCTqhIzpEWnrOB80YA4sb1IVi/MQDzUOKeS3X+WG5ImZ2qfRQp3/g1/+YAkU80Y/BtNmxVIZ/DZe+dt5zcTrUS/MNpzVmcuoiNGmls4MOsdXXmNjCXn1ScWsd8nz7wCCJnGOj8++TyMLrtf82O7W2Egw6kXXxlGC+6Y48Nbf2Kz5S3VJycsGI5H6Vir6kmFFcUsUAegGYXNqEWr9EoQz5Mw== 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=OkFwroQCQor3kIrI+oSeNCp9PmdYSXY7RBoRJohbhCQ=; b=EreKQW/aT5OvUglRWhO0sJ1hU/UBZsPcv+SPykq/JZdayzmeyE5bFWAyi2u0JB3R7IRbdnthQisLgVBlVaqFaH7j5bjhEN4HNjKRLvXA2NPvEibqp5ntaGLhLiMOQ2ZKWz9GuQ2Sd0qyJy+S6M3n/5cDjR3Ezdjx2w98uZ1QLV39GGNVZ6EtrKA6bUt8I6uDh0GhOhCF1c3nX6sXJaeMRV5EBlELOWw0hnP96775+IG9JS2LwY6AAgJrkbLrcS7Cw3DlTBo8+0pK0zW5KZvtq0ZLJhicaSnbthA0teXDstdx0iPGyqBBgWpmHbxVugZuoISOvSuStuLC9uAaIFU2vQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OkFwroQCQor3kIrI+oSeNCp9PmdYSXY7RBoRJohbhCQ=; b=es2G7N5BFvjKPR++k+npKIb52ANZNJwxFXwXkafomqJcNzum9qmq5TlYDtGKtavkR+fyqsoIAHPi/XpykPyguZb7zaK7kk37sKoqfcGnfXu0Qtgp7vZ07/LdqRsYcgVGysdBaHLOfljPf0sAb7sie9RJ332E08ectCU8NxujhezICcrLQB5a9dIXRzGMTsA8vA49kp89EDItwwIPFQg2+y9ba5xCvA/M0eCCrNZblwkCM5YUBun9JlDjKCGnJfrHp/1s7qhAMvTEoM9tUKWdVBUWI/fKJ0ErgePQR2xWoKmnRz+QIxFTFwSejxSzSrGS6RDKcbfK7R8dtHTR8UJ+4Q== Received: from BY3PR19MB4900.namprd19.prod.outlook.com (2603:10b6:a03:354::11) by CO6PR19MB5452.namprd19.prod.outlook.com (2603:10b6:303:14f::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6500.14; Thu, 8 Jun 2023 18:27:06 +0000 Received: from BY3PR19MB4900.namprd19.prod.outlook.com ([fe80::3f34:d4b:3873:2cac]) by BY3PR19MB4900.namprd19.prod.outlook.com ([fe80::3f34:d4b:3873:2cac%5]) with mapi id 15.20.6500.012; Thu, 8 Jun 2023 18:27:06 +0000 Message-ID: Date: Thu, 8 Jun 2023 11:27:04 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: [edk2-devel] [PATCH 2/2] UefiCpuPkg/CpuMpPei X64: Reallocate page tables in permanent DRAM To: devel@edk2.groups.io, ardb@kernel.org, Oliver Smith-Denny CC: Ray Ni , Jiewen Yao , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny , Dandan Bi , Dun Tan , Liming Gao , "Kinney, Michael D" , Michael Kubacki , Eric Dong , Rahul Kumar , Kun Qin References: <20230608172323.9096-1-ardb@kernel.org> <20230608172323.9096-3-ardb@kernel.org> <90e33c93-8965-dd26-15ed-8f6f2c5c3745@linux.microsoft.com> From: "Sean" In-Reply-To: X-TMN: [rhMm0W8vX/4IqF++IHlafWLLh9nrWuICy1bkZl2mM8VLvDqjjMGzku5lfvM2B2oR] X-ClientProxiedBy: MW3PR05CA0021.namprd05.prod.outlook.com (2603:10b6:303:2b::26) To BY3PR19MB4900.namprd19.prod.outlook.com (2603:10b6:a03:354::11) Return-Path: spbrogan@outlook.com X-Microsoft-Original-Message-ID: MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: BY3PR19MB4900:EE_|CO6PR19MB5452:EE_ X-MS-Office365-Filtering-Correlation-Id: 4c5f36d2-36e3-4200-9606-08db684df601 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zSF8j1TUU/ZInI3MiCdlHiN/iYveiUWfpllW6KS1LO3vD4MZrzmGkY3CfrGImtkQMfSFzG9FSlG+KLZlpxtaHibDxvuJtx8WlNdUX8pdiZe2z+6Y4YLfWUIaiUvbUJcOtv6wP0rLkv5BFNZ7P/UftKfbaYQ/ptJXUrmtAg/xER/huRaGFOxUCjAs3Q87gGd5P48QwMBQtd1goB7abmKxb94NKO20oyQUeprnbCtA1SMfLU4lEzQ8V6ImWDimWWyI4ETSJJmlZSc0dqeqMF6+ve5FK2ZXHX/avcVXnhNWfg9JosRJDyUhvESfZgEqchhVmdRyjvOVsHiCKRy/GGxkE5WTV9hKLBR//Zt6TqSCICmIn+HjlI6buQaXNVVGqq5/oM+GARLo2vnF6kUcJ1VtnitYLa4ZSwcl/V3fqlPro5HD3HWaKiR5wZirJBUwS1JGr+ZNibUEpGGoyCKoxZ6V5qRJClSZNEvaUvqUemexcHuuv4atPof8JOkse3nCTaMfCee7yUeKBhcA/OAPtPLSBbWxVO+PGghjuAjUwfNGkR8LnUVhu/zfjf+hE089funLUF/ik1qoXUtKzU1W9FQ9dPZ2Ar/zM06YMQo+qL3WT5ZGI2SRL1Ljt6/UI/e50hFdnQzzK59NnldsB58CzzySNA== X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?RzlkNarCfjaEnGjWmn3ATVKSioI8iq3jT2zqNLMarzSvVwqYM3rg7APxkfSu?= =?us-ascii?Q?vKj9o80M0FxGnTvd2MQzsKBS43849eua5MF1H9BNHDaPWn6N2VVxqWgkf7Dg?= =?us-ascii?Q?HlYJwizQa+hgRA2XXT34ctkMJP04V3GvZVDCiT1ratDkyuswcTYiiSqwcXNJ?= =?us-ascii?Q?DBPF8P/3c39l7OC9cVoS2ooyDksKS7TQdUbrC+IbcUyiBV4pEasdxI+AOGX7?= =?us-ascii?Q?fNav8BogK7+f/GeJIgurHYOsFvGiiLmgysxvXDvgc1hzha9X1n7oJbA1YM5k?= =?us-ascii?Q?gjUKmF0rjQlgYXiBVsHMgSgVYvQBlunM1aH4aoM1Z6ulNJkGZuzU+r4nSQhx?= =?us-ascii?Q?gHqcf+hykxS/wEqukuP4J/kIlrv+GQSaHA8fn+pSsm+Qs+D0hYelL2s0A+gV?= =?us-ascii?Q?Bde1wKPNKMvg9AxrAipqg18lZxdwkaaYbdQJTBnWMruzvuiK77/sLLAFOoGT?= =?us-ascii?Q?o0ZXdEQEKC/6IhkQVf973o/0Qbo12gpKCMFCCkeBL5li7j8/Xff6Oc4Cr2+K?= =?us-ascii?Q?t6JoPTZeLMG0JC27liJAAX5DLQ23tLwMbjU1FQiscP1TuE59wuG3DyOug6W3?= =?us-ascii?Q?YCpR//Ai7xJuk/9Wve7hM840CU7P+9XmyoXrj+0h8DY6IeJVOi/w2+v9qTW2?= =?us-ascii?Q?1ULQHEW/6s05DL9CACO+egJ/Y0RVvLRAfE13sQz+/Ay/ksAlriCI0o/FzXv1?= =?us-ascii?Q?YLQ/GUbqr1tg+K04IsiI68V78BN1lGFLC0thUWPoEEZ1oaU5sjMwI37BPLsG?= =?us-ascii?Q?R3wtOwdlO1KiNIXoI4e6pyNa9KRWaQMgjkPHGg7IsXzByrOwVgr0HaxonHuL?= =?us-ascii?Q?SbdOcU6yHGKWABhbZ82aY+oRRtzL/osZy0AQrBI658/ZVt0D2YOtiUISmWMm?= =?us-ascii?Q?g2qVmzrHXVLAIKWyao5KFv7Lh64n5sWluL0JU7w3NliC45I5eAya028eAMZ6?= =?us-ascii?Q?8LzV7mn+8HyWwxYGZAZF02S8cNvbQSr0Eqp1KWo6NZRYqfRroOrmxUkLDXMK?= =?us-ascii?Q?EJX1uCbRS1uraEvU5HDuL7aARynmFc3qh/3Tw8ypwmHb+GkJc5/8WtAI3N+a?= =?us-ascii?Q?ZBiECKoVLFa2vPg6Zb+MXJM8hp8EUXBz/JIx6V7jFJacCtD3UM05arzJUDsw?= =?us-ascii?Q?DpjUAxF9N2E+9iHvv3UBtjR8RkR3Wt8TqqOSK2SWAoSb2PO6tQuV6ItyrP6B?= =?us-ascii?Q?+zJ3kc+y5kxwcIckJqXZLFAO7fWKoVFlCE+SbT+yZq+fiMwLcC/LZoGwar2T?= =?us-ascii?Q?D3Bc31gVhFd5X4iF7tXY8RbZeE6XGve8Vkw+vo01JQ=3D=3D?= X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4c5f36d2-36e3-4200-9606-08db684df601 X-MS-Exchange-CrossTenant-AuthSource: BY3PR19MB4900.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Jun 2023 18:27:06.0259 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR19MB5452 Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 6/8/2023 10:48 AM, Ard Biesheuvel wrote: > On Thu, 8 Jun 2023 at 19:39, Oliver Smith-Denny > wrote: >> On 6/8/2023 10:23 AM, Ard Biesheuvel wrote: >>> Currently, we rely on the logic in DXE IPL to create new page tables >>> from scratch when executing in X64 mode, which means that we run with >>> the initial page tables all throughout PEI, and never enable protection= s >>> such as the CPU stack guard, even though the logic is already in place >>> for IA32. >>> >>> So let's enable the existing logic for X64 as well. This will permit us >>> to apply stricter memory permissions to code and data allocations, as >>> well as the stack, when executing in PEI. It also makes the DxeIpl logi= c >>> redundant, and should allow us to make the PcdDxeIplBuildPageTables >>> feature PCD limited to IA32 DxeIpl loading the x64 DXE core. >>> >>> When running in long mode, use the same logic that DxeIpl uses to >>> determine the size of the address space, whether or not to use 1 GB lea= f >>> entries and whether or not to use 5 level paging. Note that in long >>> mode, PEI is entered with paging enabled, and given that switching >>> between 4 and 5 levels of paging is not currently supported without >>> dropping out of 64-bit mode temporarily, all we can do is carry on >>> without changing the number of levels. >>> >> I certainly agree with extending the ability to have memory protections >> in PEI (and trying to unify across x86 and ARM (and beyond :)). >> >> A few things I am trying to understand: >> >> Does ARM today rebuild the page table in DxeIpl? Or is it using an >> earlier built page table? >> > No. Most platforms run without any page tables until the permanent > memory is installed, at which point it essentially maps what the > platform describes as device memory and as normal memory. > > >> If I understand your proposal correctly, with the addition of this >> patch, you are suggesting we can drop creating new page tables in DxeIpl >> and use only one page table throughout. > Yes. > >> Again, I like the idea of having >> mapped memory protections that continue through, but do you have >> concerns that we may end up with garbage from PEI in DXE in the page >> table? For OEMs, they may not control PEI and therefore be at the whim >> of another's PEI page table. Would you envision the GCD gets built from >> the existing page table or that the GCD gets built according to resource >> descriptor HOBs and DxeCore ensures that the page table reflects what >> the HOBs indicated? >> > If there is a reason to start with a clean slate when DxeIpl hands > over to DXE core, I'd prefer that to be a conscious decision rather > than a consequence of the X64 vs IA32 legacy. > > I think you can make a case for priming the GCD map based on resource > descriptors rather than current mappings, with the exception of DXE > core itself and the DXE mode stack. But I'd like to understand better > what we think might be wrong with the page tables as PEI leaves them. On many platforms there are different "owners" for these different parts=20 of firmware code.=C2=A0 The PEI phase is a place where the Silicon vendor a= nd=20 Platform teams must work together.=C2=A0 The Dxe Phase may have a different= =20 set of partners.=C2=A0 Industry trends definitely show more silicon vendor= =20 driven diversity in the PEI phase of the boot process and with this=20 diversity it is much harder to make solid assumptions about the=20 execution environment.=C2=A0=C2=A0 We have also discussed in the past meeti= ng that=20 PEI should be configurable using different solutions given it isn't a=20 place where unknown 3rd party compatibility is critical.=C2=A0 This means= =20 that PEI might have different requirements than DXE and thus the=20 configuration inherited from PEI may not be compliant. Additionally, the=20 code and driver mappings from PEI phase should not be relevant in DXE.=C2= =A0=20 Even with the same architecture being used these are different execution=20 phases with different constructs.=C2=A0 Keeping the PEI code mapped will on= ly=20 lead to additional security and correctness challenges.=C2=A0 Finally, as a= n=20 overarching theme of this project we have suggested we should not be=20 coupling the various phases, their requirements, and their assumptions=20 together.=C2=A0 You could just as easily apply this to DXE and SMM/MM.=C2= =A0 These=20 are all independent execution environments and the more we can provide=20 simplification and consistency the better our chances are of getting=20 correct implementations across the ecosystem. > > >=20 > >