[edk2-devel] managing memory attributes in PEI

[Michael D Kinney]

Ard,

I would prefer to keep the IA32 PEI support for OVMF.  

Ray had proposed an idea to introduce a library class to help
with the DXEIPL complexity.  Perhaps that can be combines with
this effort.

Mike

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



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#105195): https://edk2.groups.io/g/devel/message/105195
Mute This Topic: https://groups.io/mt/99062463/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/3943202/1813853/130120423/xyzzy [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-