Re: managing memory attributes in PEI

["Ni, Ray" <ray.ni@intel.com>]

> -----Original Message-----
> From: Laszlo Ersek <lersek@redhat.com>
> Sent: Tuesday, May 23, 2023 1:31 PM
> To: Ard Biesheuvel <ardb@kernel.org>; edk2-devel-groups-io
> <devel@edk2.groups.io>; Ni, Ray <ray.ni@intel.com>; Yao, Jiewen
> <jiewen.yao@intel.com>; Gerd Hoffmann <kraxel@redhat.com>; Taylor Beebe
> <t@taylorbeebe.com>; Oliver Smith-Denny <osd@smith-denny.com>
> Subject: Re: managing memory attributes in PEI
> 
> 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.

Wow. I didn't realize OVMF had S3Verification() to explicitly educate users
X64 PEI + SMM doesn't support S3.:)
That will be great to remove the code today.

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

I don't quite understand. So, what's the conclusion of IA32X64 OVMF? Keep it? Remove it?