From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by mx.groups.io with SMTP id smtpd.web10.3461.1686252772024079320 for ; Thu, 08 Jun 2023 12:32:52 -0700 Authentication-Results: mx.groups.io; dkim=fail reason="body hash did not verify" header.i=@linux.microsoft.com header.s=default header.b=G7o4eCwQ; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: mikuback@linux.microsoft.com) Received: from [192.168.4.22] (unknown [47.201.8.94]) by linux.microsoft.com (Postfix) with ESMTPSA id E345720C1467; Thu, 8 Jun 2023 12:32:49 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E345720C1467 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1686252771; bh=tVV7A7LCVEs4r6gKQzCi08YCOnOOKvEgOMoxlNUWzWY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=G7o4eCwQxyfNS7clIIzCNkIhdWPqNZboUVAemBRN3ZmlfxCY6/IWjKCofq0UUAstB M72jOFzKJu2+Y+qUC3waSUb39ulcfp6ZBJHENfj7Eou7PM4e0k0o9eTcPvX2OadjH4 abMGoc+zJAZjn5vJ7pK4fqGkN8g3GISplZkwwAdA= Message-ID: <7f309bc4-5900-491e-c526-3ab04e23e947@linux.microsoft.com> Date: Thu, 8 Jun 2023 15:32:48 -0400 MIME-Version: 1.0 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, spbrogan@outlook.com, 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" , 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: "Michael Kubacki" In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I think Sean's point aligns more closely with traditional PI boot phase=20 separation goals. Btw, in the project we discussed, this issue was meant=20 to capture the DXE memory protection init dependencies -=20 https://github.com/tianocore/edk2/issues/4502 if someone would like to=20 update that at some point. Thanks, Michael On 6/8/2023 2:27 PM, Sean wrote: > 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=20 >>>> protections >>>> 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 u= s >>>> to apply stricter memory permissions to code and data allocations, as >>>> well as the stack, when executing in PEI. It also makes the DxeIpl=20 >>>> logic >>>> 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=20 >>>> leaf >>>> 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 DxeIp= l >>> 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 resourc= e >>> 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. >=20 >=20 > 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= and=20 > Platform teams must work together.=C2=A0 The Dxe Phase may have a differe= nt=20 > set of partners.=C2=A0 Industry trends definitely show more silicon vendo= r=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 mee= ting 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.=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 = only=20 > lead to additional security and correctness challenges.=C2=A0 Finally, as= an=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 >> >> >> >> >> >=20 >=20 >=20 >=20