Re: managing memory attributes in PEI

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

On Tue, 23 May 2023 at 09:34, Laszlo Ersek <lersek@redhat.com> wrote:
>
> On 5/23/23 07:39, Ni, Ray wrote:
> >
> >
> >> -----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?
> >
>
> As long as edk2 (core modules) will continue supporting IA32X64 firmware
> platforms, I think keeping OVMF IA32X64 is useful, minimally as a test
> bed for those core modules / PCDs / boot paths. If it becomes difficult
> / costly to maintain OVMF IA32X64, then removing it might make sense at
> some point, but I don't think it's time for that already.
>
> So right now I'd just consider "shifting emphasis" from OVMF IA32X64 to
> OVMF X64.
>
> And of course this is just my opinion.
>

Thanks Laszlo. I tend to agree.

It will just mean that IA32X64 will be left behind in terms of future
enhancements. IOW, I am not going to bother catering for IA32X64 when
proposing a memory attributes PPI that manages page table permissions
for shadowed PEIMs and the DXE core. I don't think anyone would mind
that.