Re: managing memory attributes in PEI

["Laszlo Ersek" <lersek@redhat.com>]

On 5/22/23 13:31, Ard Biesheuvel wrote:
> 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)

For a long time, IA32X64 had been required if you wanted (a) X64 DXE,
(b) SMM, and (c) ACPI S3 resume. The reason was that
UefiCpuPkg/Universal/Acpi/S3Resume2Pei didn't support SMM on X64, only
on IA32.

See commit 5133d1f1d297 ("OvmfPkg: replace README fine print about X64
SMM S3 with PlatformPei check", 2015-11-30).

This S3Resume2Pei limitation got lifted last year, in commit
6acf72901a2e ("UefiCpuPkg: Supporting S3 in 64bit PEI", 2022-12-19), for
<https://bugzilla.tianocore.org/show_bug.cgi?id=4195>.

Gerd tested the according removal of S3Verification() in OVMF
<https://bugzilla.tianocore.org/show_bug.cgi?id=4195#c4>, but that code
is not upstream (or downstream at that, IIUC), yet.

Once S3Verification() is removed, OVMF IA32X64 will remain useful for
exercising a particular IA32X64 combination of modules that physical
platforms use, but I reckon IA32X64 will no longer be required for
virtualization purposes per se.

Before we enabled SMM for OVMF, we had never really used IA32X64 OVMF --
SMM-less ACPI S3 resume had just worked fine with X64-only OVMF. IA32X64
only proved a great platform option to fall back to, when we realized
that on X64 OVMF, ACPI S3 resume wouldn't just seamlessly extend to SMM.

Thanks,
Laszlo

> - 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.
>