Re: [PATCH] loader/i386/linux: Prefer entry in long mode when booting via EFI

[Daniel Kiper]

On Wed, Sep 06, 2023 at 11:19:55AM +0200, Ard Biesheuvel wrote:
> On Mon, 21 Aug 2023 at 20:10, Ard Biesheuvel <ardb@kernel.org> wrote:
> > On Thu, 3 Aug 2023 at 15:24, Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > The x86_64 Linux kernel can be booted in 32-bit mode, in which case the
> > > startup code creates a set of preliminary page tables that map the first
> > > 1GiB of physical memory 1:1, and enables paging. This is a prerequisite
> > > for 64-bit execution, and can therefore only be implemented in 32-bit
> > > code.
> > >
> > > The x86_64 Linux kernel can also be booted in 64-bit mode directly: this
> > > implies that paging is already enabled, and it is the responsibility of
> > > the bootloader to ensure that the the active page tables cover the
> > > entire loaded image, including its BSS space, the size of which is
> > > described in the image's setup header.
> > >
> > > Given that the EFI spec mandates execution in long mode for x86_64, and
> > > stipulates that all system memory is mapped 1:1, the Linux/x86
> > > requirements for 64-bit entry can be met trivially when booting on
> > > x86_64 via EFI. So enter via the 64-bit entrypoint in this case.
> > >
> > > This involves inspecting the xloadflags field in the setup header to
> > > check whether the 64-bit entrypoint is supported. This field was
> > > introduced in Linux version v3.8 (early 2013)
> > >
> > > This change ensures that all EFI firmware tables and other assets passed
> > > by the firmware or bootloader in memory remain mapped and accessible
> > > throughout the early startup code. (Note that Linux's 32-bit startup
> > > code creates multiple shadow mappings of the first 1GiB of physical
> > > memory up to the 4 GiB mark so anything that resides there becomes
> > > inaccessible until the 64-bit startup code replaces the preliminary
> > > mappings with more accurate ones)
> > >
> > > Avoiding the drop out of long mode will also be needed to support
> > > upcoming CPU designs that no longer implement 32-bit mode at all (as
> > > recently announced by Intel [0])
> > >
> > > [0] 
> > > https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
> > >
> > > Cc: Daniel Kiper <daniel.kiper@oracle.com>
> > > Cc: Julian Andres Klode <julian.klode@canonical.com>
> > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> >
> > Ping?
>
> Ping?
>
> This should preferably be part of the release so we avoid failing back
> to 32-bit entry for configurations that may have been using the
> handover protocol in the past.

I am busy with the other GRUB stuff. I remember about this patch and
will get back to you ASAP. Sorry for delay...

Daniel