managing memory attributes in PEI

["Ard Biesheuvel" <ardb@kernel.org>]

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.