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