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.17572.1685035260636279986 for ; Thu, 25 May 2023 10:21:00 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@linux.microsoft.com header.s=default header.b=pwfyd7VL; 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 095F620FBE87; Thu, 25 May 2023 10:21:00 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 095F620FBE87 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1685035260; bh=gTPxvptd8KZwTbFbUv2lO3Jv446odfBgOaMfEerqNqI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=pwfyd7VLUye83CL4QqzUtGkKUzhZGjVqL0tu0aIcqVHMDJJrLSOeSnlD2Xc8G1kl9 n7w0gK6llEVCWgf7Bx2kT+O2LVJJ9rWP4G6sItlSKK2Q2jR6RXI9+b3xaAbIruG3YP hY4NspMcoQLdSugsK38BUBbC80V+ObWbm0NHO6bg= Message-ID: Date: Thu, 25 May 2023 10:20:59 -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] [RFC PATCH 00/10] Add PPI to manage PEI phase memory attributes To: devel@edk2.groups.io, ardb@kernel.org Cc: Ray Ni , Jiewen Yao , Gerd Hoffmann , Taylor Beebe , Oliver Smith-Denny , Dandan Bi , Liming Gao , "Kinney, Michael D" , Leif Lindholm , Sunil V L , Andrei Warkentin References: <20230525143041.1172989-1-ardb@kernel.org> From: "Oliver Smith-Denny" In-Reply-To: <20230525143041.1172989-1-ardb@kernel.org> Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 5/25/2023 7:30 AM, Ard Biesheuvel wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4468 > > > > This is a proof-of-concept RFC that implements a PEI phase PPI to manage > > memory permission attributes, and wires it up to the PEI image loader so > > that shadowed PEIMs as well as the DXE core are remapped with the > > appropriate, restricted memory permission attributes before execution. > > > > This means that neither shadowed PEIMs nor the DXE core will ever > > execute with writable code regions. It also removes the need on the part > > of PEI for memory to be mapped with both writable and executable > > permissions by default out of reset. Similar work still needs to be done > > to address the early DXE phase (before the CPU arch protocol becomes > > available), but once that is out of the way as well, platforms should be > > able to map all memory non-executable from the beginning. > > > > This by itself is a major improvement in terms of robustness. It is also > > a prerequisite for enabling the WXN MMU control on AArch64, which makes > > all writable memory mappings non-executable regardless of the non-exec > > page table attribute. > > > > Patches #1 to #4 are prepatory work. > > Patch #5 proposes the memory attribute PPI protocol interface. > > Patch #6 implements it for ARM and AARCH64. > > Patch #7 wires it up into the PEI image loader. > > Patches #8 to #10 update the DxeIpl to use this PPI on ARM/AARCH64 for > > mapping the stack NX. > > instead of an explicit reference to ArmMmuLib. Other architectures > > (except IA32/X64) will seamlessly inherit this once they implement the > > PPI as well. > Hi Ard, Thanks for the RFC. This same issue exists for X64, I saw your mailing list question about IA32 PEI, do you have plans for extending this to X64 PEI (I'm not sure its state of readiness)? If so, do you think it is feasible to merge the X64 DxeLoadFunc with the generic one you have created? Overall, this seems a reasonable approach to me towards making DXE more protected with the additional benefit of protecting shadowed PEIMs. I did wonder if the same discussion we are having on the DXE side about moving these MMU manipulations to the core instead of the CPU driver make sense in PEI, too, but with the greatly reduced complexity of the environment (no GCD, etc.), I don't think it makes sense now and that focusing on the DXE reorganization and expansion is going to deliver a much greater impact. Thanks, Oliver