From: "Oliver Smith-Denny" <osde@linux.microsoft.com>
To: devel@edk2.groups.io, ardb@kernel.org
Cc: Ray Ni <ray.ni@intel.com>, Jiewen Yao <jiewen.yao@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Taylor Beebe <t@taylorbeebe.com>,
Oliver Smith-Denny <osd@smith-denny.com>,
Dandan Bi <dandan.bi@intel.com>,
Liming Gao <gaoliming@byosoft.com.cn>,
"Kinney, Michael D" <michael.d.kinney@intel.com>,
Leif Lindholm <quic_llindhol@quicinc.com>,
Sunil V L <sunilvl@ventanamicro.com>,
Andrei Warkentin <andrei.warkentin@intel.com>
Subject: Re: [edk2-devel] [RFC PATCH 00/10] Add PPI to manage PEI phase memory attributes
Date: Thu, 25 May 2023 10:20:59 -0700 [thread overview]
Message-ID: <c202b14e-e1c9-70dd-ee6d-acea74b84642@linux.microsoft.com> (raw)
In-Reply-To: <20230525143041.1172989-1-ardb@kernel.org>
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
next prev parent reply other threads:[~2023-05-25 17:21 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-25 14:30 [RFC PATCH 00/10] Add PPI to manage PEI phase memory attributes Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 01/10] ArmPkg/ArmMmuLib: Extend API to manage memory permissions better Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 02/10] ArmPkg/CpuDxe: Simplify memory attributes protocol implementation Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 03/10] ArmPkg/CpuPei: Drop bogus DEPEX on PEI permanent memory Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 04/10] OvmfPkg/RiscVVirt: Remove unimplemented NxForStack configuration Ard Biesheuvel
2023-05-29 12:50 ` Sunil V L
2023-05-25 14:30 ` [RFC PATCH 05/10] MdeModulePkg: Define memory attribute PPI Ard Biesheuvel
2023-05-30 7:15 ` Ni, Ray
2023-05-30 7:32 ` Ard Biesheuvel
2023-05-31 7:33 ` Ni, Ray
2023-05-31 7:53 ` Ard Biesheuvel
2023-05-31 8:56 ` [edk2-devel] " Ni, Ray
2023-05-31 9:24 ` Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 06/10] ArmPkg/CpuPei: Implement the memory attributes PPI Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 07/10] MdeModulePkg/PeiCore: Apply restricted permissions in image loader Ard Biesheuvel
2023-05-25 17:21 ` [edk2-devel] " Oliver Smith-Denny
2023-05-25 21:29 ` Ard Biesheuvel
2023-05-30 16:51 ` Oliver Smith-Denny
2023-05-30 20:51 ` Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 08/10] MdeModulePkg/DxeIpl: Merge EBC, RISCV64 and LOONGARCH code Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 09/10] MdeModulePkg/DxeIpl: Use memory attribute PPI to remap the stack NX Ard Biesheuvel
2023-05-30 7:19 ` Ni, Ray
2023-05-30 10:25 ` duntan
2023-05-30 12:51 ` Ard Biesheuvel
2023-05-31 7:22 ` Gerd Hoffmann
2023-05-31 1:29 ` Ni, Ray
2023-05-31 19:03 ` [edk2-devel] " Lendacky, Thomas
2023-05-31 21:01 ` Ard Biesheuvel
2023-05-25 14:30 ` [RFC PATCH 10/10] MdeModulePkg/DxeIpl ARM AARCH64: Switch to generic handoff code Ard Biesheuvel
2023-05-25 17:20 ` Oliver Smith-Denny [this message]
2023-05-25 21:43 ` [edk2-devel] [RFC PATCH 00/10] Add PPI to manage PEI phase memory attributes Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c202b14e-e1c9-70dd-ee6d-acea74b84642@linux.microsoft.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox