[edk2-devel] Side effects of enabling PML5 in EFI

[Ard Biesheuvel]

On Tue, 9 May 2023 at 19:24, Pedro Falcato <pedro.falcato at gmail.com> wrote:
>
> Hi all,
>
> (+CC people vaguely related to the EFI spec, the PML5 implementation
> and kernel EFI boot code)
>
> As a result of the latest 5-level paging patches, I've been looking
> into how tiano supports PML5.
> This raised a question: Doesn't enabling PML5 in-firmware break
> compatibility with non-PML5-aware bootloaders and kernels?
>
> From an architectural point of view:
> - PML5 is enabled in CR4.LA57, but may only be toggled when not in
> IA32e mode (so, only in 32-bit)
> - Trying to mindlessly write to CR4 will #GP, and loading a 4-level
> page tables will crash with probable page faults or #GPs
>
> From an EFI spec point of view:
> - Whereas other architectures (arm64 for instance) specify the MMU
> state in detail, the x64 bits do not specify anything beyond "Paging
> enabled" (see 2.3.4). Which pre-PML5, was obviously well defined.

We actually have a related problem on ARM: the size of the virtual
address space is not mandated by the spec, but it does require that
all memory is mapped 1:1.

This means that, if a system has any memory that is outside of the
48-bit physical range, it must enable 5 level paging to map it 1:1 in
the 52-bit virtual range.

Given that EDK2's page allocator allocates from top down from the end
of the address space, we might end up with allocations for ACPI tables
etc that cannot be mapped by kernels that do not implement support for
5 level paging.

I imagine a similar issue might exist on x86 as well, and this
suggests that using 5 level paging in the firmware is only sensible if
it is guaranteed that the OS and loader can deal with it (IOW, running
the firmware with 5 level pages and switching back to 4 in
ExitBootServices() may result in other issues)

> - When under boot services, this is likely not a problem as page
> tables are owned by boot services. Unless they touch them as defined
> in "2.3.4.3. Enabling Paging or Alternate Translations in an
> Application", which may run into problems.
>
> From an OS kernel/bootloader point of view:
> - A PML5 aware kernel/bootloader will likely correctly identify the
> PML5 capability and enable LA57, load 5-level page tables. As such,
> this scenario always works.
> - A non-PML5-aware one may incorrectly overwrite LA57 (and #GP), or
> just load a 4-level paging structure into CR3, and thus disastrously
> crash.
>
> So, how is any of this supposed to work?
>

I don't think the firmware should ever use 5 level paging unless it is
strictly needed for a particular use case. And even then, it should
avoid allocating memory from the region that is only 1:1 accessible
when 5 level paging is enabled.


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