linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Michael Roth <michael.roth@amd.com>
Subject: Re: [PATCH v2 03/16] x86/compressed: efi-mixed: move bootargs parsing out of 32-bit startup code
Date: Thu, 6 Oct 2022 13:29:55 +0200	[thread overview]
Message-ID: <CAMj1kXGfMp_nquvL2ECchof_BMZ54tZK5JwrXno4VO6nGCJVAA@mail.gmail.com> (raw)
In-Reply-To: <Yz615Qc1K284jlH9@zn.tnic>

On Thu, 6 Oct 2022 at 13:03, Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Sep 21, 2022 at 04:54:09PM +0200, Ard Biesheuvel wrote:
> > Move the logic that chooses between the different EFI entrypoints out of
> > the 32-bit boot path, and into a 64-bit helper that can perform the same
> > task much more cleanly. While at it, document the mixed mode boot flow
> > in a code comment.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> >  arch/x86/boot/compressed/efi_mixed.S | 43 ++++++++++++++++++++
> >  arch/x86/boot/compressed/head_64.S   | 24 ++---------
> >  2 files changed, 47 insertions(+), 20 deletions(-)
> >
> > diff --git a/arch/x86/boot/compressed/efi_mixed.S b/arch/x86/boot/compressed/efi_mixed.S
> > index 67e7edcdfea8..77e77c3ea393 100644
> > --- a/arch/x86/boot/compressed/efi_mixed.S
> > +++ b/arch/x86/boot/compressed/efi_mixed.S
> > @@ -22,6 +22,49 @@
> >
> >       .code64
> >       .text
> > +/*
> > + * When booting in 64-bit mode on 32-bit EFI firmware, startup_64_mixedmode()
> > + * is the first thing that runs after switching to long mode. Depending on
> > + * whether the EFI handover protocol or the compat entry point was used to
> > + * enter the kernel, it will either branch to the 64-bit EFI handover
> > + * entrypoint at offset 0x390 in the image, or to the 64-bit EFI PE/COFF
> > + * entrypoint efi_pe_entry(). In the former case, the bootloader must provide a
> > + * struct bootparams pointer as the third argument, so the presence of such a
> > + * pointer is used to disambiguate.
> > + *
> > + *                                                             +--------------+
> > + *  +------------------+     +------------+            +------>| efi_pe_entry |
> > + *  | efi32_pe_entry   |---->|            |            |       +-----------+--+
> > + *  +------------------+     |            |     +------+---------------+   |
> > + *                           | startup_32 |---->| startup_64_mixedmode |   |
> > + *  +------------------+     |            |     +------+---------------+   V
> > + *  | efi32_stub_entry |---->|            |            |     +------------------+
> > + *  +------------------+     +------------+            +---->| efi64_stub_entry |
> > + *                                                           +-------------+----+
> > + *                           +------------+     +----------+               |
> > + *                           | startup_64 |<----| efi_main |<--------------+
> > + *                           +------------+     +----------+
> > + */
>
> That is much appreciated.
>
> Questions:
>
> - is this whole handover ABI documented somewhere?
>

Documentation/x86/boot.rst has a section on this (at the end), but we
should really stop using it. It is only implemented by out-of-tree
GRUB at the moment (last time I checked) and leaking all those struct
bootparams specific details into every bootloader is not great,
especially the ones that intend to be generic and boot any EFI OS on
any EFI arch.


> - efi32_pe_entry() is the 32-bit PE/COFF entry point? I.e., that is
> called by a 32-bit EFI fw when the kernel is a PE/COFF executable?
>

Yes. But I should note that this is actually something that goes
outside of the EFI spec as well: 32-bit firmware can /load/ 64-bit
PE/COFF binaries but not *start* them.

Commit 97aa276579b28b86f4a3e235b50762c0191c2ac3 has some more
background. This is currently implement by 32-bit OVMF, and
systemd-boot.

> But then Documentation/admin-guide/efi-stub.rst talks about the EFI stub
> and exactly that. Hmm, so what is efi32_pe_entry() then?
>

That is the same thing. The EFI stub is what enables the kernel (or
decompressor) to masquerade as a PE/COFF executable.

In short, every EFI stub kernel on every architecture has a native
PE/COFF entry point that calls the EFI stub, and the EFi stub does the
arch-specific bootloader work and boots it.

In addition, the x86_64 EFI stub kernel has an extra, non-native
PE/COFF entry point, which is exposed in a way that is not covered by
the EFI spec, but which allows Linux specific loaders such as
systemd-boot to boot such kernels on 32-bit firmware without having to
do the whole struct bootparams dance in the bootloader.

  reply	other threads:[~2022-10-06 11:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-21 14:54 [PATCH v2 00/16] x86: head_64.S spring cleaning Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 01/16] x86/compressed: efi-mixed: rename efi_thunk_64.S to efi-mixed.S Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 02/16] x86/compressed: efi-mixed: move 32-bit entrypoint code into .text section Ard Biesheuvel
2022-10-06 10:42   ` Borislav Petkov
2022-10-06 10:56     ` Ard Biesheuvel
2022-10-06 11:13       ` Borislav Petkov
2022-10-06 11:19         ` Ard Biesheuvel
2022-10-06 12:27           ` Ard Biesheuvel
2022-10-07  8:56             ` Borislav Petkov
2022-09-21 14:54 ` [PATCH v2 03/16] x86/compressed: efi-mixed: move bootargs parsing out of 32-bit startup code Ard Biesheuvel
2022-10-06 11:03   ` Borislav Petkov
2022-10-06 11:29     ` Ard Biesheuvel [this message]
2022-10-07  9:30       ` Borislav Petkov
2022-09-21 14:54 ` [PATCH v2 04/16] x86/compressed: efi-mixed: move efi32_pe_entry into .text section Ard Biesheuvel
2022-11-17 15:57   ` Borislav Petkov
2022-11-17 16:06     ` Ard Biesheuvel
2022-11-17 17:08       ` Borislav Petkov
2022-09-21 14:54 ` [PATCH v2 05/16] x86/compressed: efi-mixed: move efi32_entry out of head_64.S Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 06/16] x86/compressed: efi-mixed: move efi32_pe_entry() " Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 07/16] x86/compressed: efi: merge multiple definitions of image_offset into one Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 08/16] x86/compressed: efi-mixed: simplify IDT/GDT preserve/restore Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 09/16] x86/compressed: avoid touching ECX in startup32_set_idt_entry() Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 10/16] x86/compressed: pull global variable ref up into startup32_load_idt() Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 11/16] x86/compressed: move startup32_load_idt() into .text section Ard Biesheuvel
2022-11-18 16:44   ` Borislav Petkov
2022-09-21 14:54 ` [PATCH v2 12/16] x86/compressed: move startup32_load_idt() out of head_64.S Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 13/16] x86/compressed: move startup32_check_sev_cbit() into .text Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 14/16] x86/compressed: move startup32_check_sev_cbit() out of head_64.S Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 15/16] x86/compressed: adhere to calling convention in get_sev_encryption_bit() Ard Biesheuvel
2022-09-21 14:54 ` [PATCH v2 16/16] x86/compressed: only build mem_encrypt.S if AMD_MEM_ENCRYPT=y Ard Biesheuvel
2022-11-18 18:26 ` [PATCH v2 00/16] x86: head_64.S spring cleaning Borislav Petkov
2022-11-18 23:31   ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXGfMp_nquvL2ECchof_BMZ54tZK5JwrXno4VO6nGCJVAA@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.roth@amd.com \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).