If feasible as to time and effort, I would like to introduce W^X execution to EDK II DXE. Even if this cannot happen short-term, the design should be embraced anyway to increase code security and reliability. The W^X principle allows for tighter memory permissions and more effective guarding of memory, for both debug and production. Data should be copied to *Code memory if and only if it's instructions that can be directly executed by the host CPU, and any other data in the regions should either be 0 (common default) or an architecture-specific value to ensure safe execution even when the padding is executed (e.g. 0xCC for x86 architectures, which is INT3). Similarly, a page should be executable if and only if it currently contains "live code" that fits the previous description. This most notably disallows storing data together with code on the same page, which unfortunately is common practice right now[1][2] (not comprehensive). [1] https://github.com/tianocore/edk2/blob/2072c22a0d63c780b0cc6377f6d4ffb116ad6144/UefiCpuPkg/Library/MpInitLib/MpLib.c#L1200-L1203 [2] https://github.com/tianocore/edk2/blob/2072c22a0d63c780b0cc6377f6d4ffb116ad6144/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchInterruptDefs.h#L37
Marvin, you can continue to provide the proposal.
Marvin: current edk2 has enabled the protection for runtime and smm modules. This protection can also be applied for DXE module.
The problem is not the protection infrastructure, but data separation - please refer to [1] and [2] as suiting but non-comprehensive examples. Only once all these issues have been fixed, protection can be reliably enabled. It will then also need PCD toggles to loosen the policies for third-party code (OpROMs and boot loaders), to not unintentionally break compatibility.
