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

[Daniel Kiper]

On Mon, Aug 21, 2023 at 09:51:13PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> I think we need to start having options to specify which entry to use. E.g
> linux --no-efi-stub /vmlinuz
> This is probably needed to support other users of Linux protocol

If somebody needs that thing they can add it later.

For now Reviewed-by: Daniel Kiper <daniel.kiper@oracle.com>...

Though...

> Le lun. 21 août 2023, 20:12, Ard Biesheuvel <ardb@kernel.org> a écrit :
>      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?
>
>      > ---
>      >  grub-core/loader/i386/linux.c | 12 ++++++++++++
>      >  include/grub/i386/linux.h     | 15 +++++++++++++--
>      >  2 files changed, 25 insertions(+), 2 deletions(-)
>      >
>      > diff --git a/grub-core/loader/i386/linux.c b/grub-core/loader/i386/
>      linux.c
>      > index 997647a33326eeb8..a83cc52a656d587b 100644
>      > --- a/grub-core/loader/i386/linux.c
>      > +++ b/grub-core/loader/i386/linux.c
>      > @@ -624,6 +624,18 @@ grub_linux_boot (void)
>      >    }
>      >  #endif
>      >
>      > +#if defined (GRUB_MACHINE_EFI) && defined (__x86_64__)

... I would put "defined (__x86_64__)" first in the condition. I can
make it for you before push.

Daniel