Hello all, (OVMF specific questions below - please keep reading)
As a follow-up to the discussion we had last week regarding DXE core, I'd like to raise the issue of managing memory permissions in PEI, including the mapping attributes of the code and data regions of DXE core itself. This is about good hygiene in general, but on arm64 in particular, limiting execution permissions to memory regions that are mapped read-only allows the MMU to be enabled in WXN mode, where all writable regions are non-executable by default. I have implemented a proof-of-concept of this for ArmVirtQemu and Raspberry Pi 4 (the former using PEI and the latter PEI-less), and this seems quite feasible in practice, but there are a few issues that I have identified: - PEI shadowing is currently disabled entirely - this is actually an advantage for the [virtual] platform in question, given that shadowing is more work for no benefit, but it is something that needs to be addressed in the general case; - no generic method exists to manage page table permissions. So what I would like to propose (and what I intend to prototype) is a PPI that abstracts this capability, and which can be used by the PEI image loader as well as the DxeIpl to manage read-only and non-exec permissions. Most PEIMs only have a code region anyway, so hopefully there is some room for optimization where not all PEIMs need 4k alignment. That leaves one big issue, and this is related to OVMF's use of IA32 PEI with X64 DXE. This complicates the DxeIpl substantially already, but would make this effort rather tricky as well. So my questions are: - do we need to retain mixed IA32 / X64 support, and if so, why? (I think it is related to SMM emulation but I need someone to confirm this) - if we need to retain it, could we run PEI in long mode but with 32-bit compatibility enabled, so that we don't need two or three incompatible sets of page tables? In the latter case, the PPI in question would carry the same logic for IA32 and X64 builds, and create 4-level page tables with the code still being 32-bit. Once we clear this up, I'm happy to look into extending my prototype to x86 as well. Thanks, Ard. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#105115): https://edk2.groups.io/g/devel/message/105115 Mute This Topic: https://groups.io/mt/99062463/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
