[edk2-devel] managing memory attributes in PEI

[Laszlo Ersek]

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 (#105157): https://edk2.groups.io/g/devel/message/105157
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]
-=-=-=-=-=-=-=-=-=-=-=-