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.web11.503.1686245946583118288 for ; Thu, 08 Jun 2023 10:39:06 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=TW1qN23x; spf=pass (domain: linux.microsoft.com, ip: 13.77.154.182, mailfrom: osde@linux.microsoft.com) Received: from [10.137.194.171] (unknown [131.107.1.171]) by linux.microsoft.com (Postfix) with ESMTPSA id EFB0220C145B; Thu, 8 Jun 2023 10:39:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com EFB0220C145B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1686245946; bh=6FS3znLx9vppqJzIj4oqcZdmR+DCnNhIULghzLng3lU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TW1qN23xTt1xrkdNvvluRnd/RoPEYVcriO8rZN8x236hBPw7uWd4SQj//ymG/oPLa eYB0tT7Gn1SJ3STXxt+G0GUmmFjyzQA+hWQMpzqDmiBS3J3lmQeuYEMrUU8q5pDFlM GhhRE7ajb+U+D1/S5ZwU7JXUXJP5zv7cs6Juw6SM= Message-ID: <90e33c93-8965-dd26-15ed-8f6f2c5c3745@linux.microsoft.com> Date: Thu, 8 Jun 2023 10:39:05 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [edk2-devel] [PATCH 2/2] UefiCpuPkg/CpuMpPei X64: Reallocate page tables in permanent DRAM To: devel@edk2.groups.io, ardb@kernel.org 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> From: "Oliver Smith-Denny" In-Reply-To: <20230608172323.9096-3-ardb@kernel.org> Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 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 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 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 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? 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. 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? Thanks, Oliver