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

[Ard Biesheuvel]

On Thu, 14 Sept 2023 at 18:31, Daniel Kiper <dkiper@net-space.pl> wrote:
>
> 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.
>

That's fine.