All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: linux-efi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Michael Roth <michael.roth@amd.com>
Subject: [PATCH v3 17/17] efi: x86: Make the deprecated EFI handover protocol optional
Date: Tue, 22 Nov 2022 17:10:17 +0100	[thread overview]
Message-ID: <20221122161017.2426828-18-ardb@kernel.org> (raw)
In-Reply-To: <20221122161017.2426828-1-ardb@kernel.org>

The EFI handover protocol permits a bootloader to invoke the kernel as a
EFI PE/COFF application, while passing a bootparams struct as a third
argument to the entrypoint function call.

This has no basis in the UEFI specification, and there are better ways
to pass additional data to a UEFI application (UEFI configuration
tables, UEFI variables, UEFI protocols) than going around the
StartImage() boot service and jumping to a fixed offset in the loaded
image, just to call a different function that takes a third parameter.

The reason for handling struct bootparams in the bootloader was that the
EFI stub could only load initrd images from the EFI system partition,
and so passing it via struct bootparams was needed for loaders like
GRUB, which pass the initrd in memory, and may load it from anywhere,
including from the network. Another motivation was EFI mixed mode, which
could not use the initrd loader in the EFI stub at all due to 32/64 bit
incompatibilities (which will be fixed shortly [0]), and could not
invoke the ordinary PE/COFF entry point either, for the same reasons.

Given that loaders such as GRUB already carried the bootparams handling
in order to implement non-EFI boot, retaining that code and just passing
bootparams to the EFI stub was a reasonable choice (although defining an
alternate entrypoint could have been avoided.) However, the GRUB side
changes never made it upstream, and are only shipped by some of the
distros in their downstream versions.

In the meantime, EFI support has been added to other Linux architecture
ports, as well as to U-boot and systemd, including arch-agnostic methods
for passing initrd images in memory [1], and for doing mixed mode boot
[2], none of them requiring anything like the EFI handover protocol. So
given that only out-of-tree distro GRUB relies on this, let's permit it
to be omitted from the build, in preparation for retiring it completely
at a later date. (Note that systemd-boot does have an implementation as
well, but only uses it as a fallback for booting images that do not
implement the LoadFile2 based initrd loading method, i.e., v5.8 or older)

[0] https://lore.kernel.org/all/20220927085842.2860715-1-ardb@kernel.org/
[1] ec93fc371f01 ("efi/libstub: Add support for loading the initrd ...")
[2] 97aa276579b2 ("efi/x86: Add true mixed mode entry point into ...")

Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
 arch/x86/Kconfig                   | 17 +++++++++++++++++
 arch/x86/boot/compressed/head_64.S |  4 +++-
 arch/x86/boot/header.S             |  2 +-
 arch/x86/boot/tools/build.c        |  2 ++
 4 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 8c6da5e42d5a6c25..121f1fdca3145fd2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1981,6 +1981,23 @@ config EFI_STUB
 
 	  See Documentation/admin-guide/efi-stub.rst for more information.
 
+config EFI_HANDOVER_PROTOCOL
+	bool "EFI handover protocol (DEPRECATED)"
+	depends on EFI_STUB
+	default y
+	help
+	  Select this in order to include support for the deprecated EFI
+	  handover protocol, which defines alternative entry points into the
+	  EFI stub.  This is a practice that has no basis in the UEFI
+	  specification, and requires a priori knowledge on the part of the
+	  bootloader about Linux/x86 specific ways of passing the command line
+	  and initrd, and where in memory those assets may be loaded.
+
+	  If in doubt, say Y. Even though he corresponding support is not
+	  present in upstream GRUB or other bootloaders, most distros build
+	  GRUB with numerous downstream patches applied, and may rely on the
+	  handover protocol as as result.
+
 config EFI_MIXED
 	bool "EFI mixed-mode support"
 	depends on EFI_STUB && X86_64
diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
index dd18216cff5c37e0..a75712991df3e936 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -294,7 +294,7 @@ SYM_FUNC_START(startup_32)
 	lret
 SYM_FUNC_END(startup_32)
 
-#ifdef CONFIG_EFI_MIXED
+#if IS_ENABLED(CONFIG_EFI_MIXED) && IS_ENABLED(CONFIG_EFI_HANDOVER_PROTOCOL)
 	.org 0x190
 SYM_FUNC_START(efi32_stub_entry)
 	add	$0x4, %esp		/* Discard return address */
@@ -524,7 +524,9 @@ trampoline_return:
 SYM_CODE_END(startup_64)
 
 #ifdef CONFIG_EFI_STUB
+#ifdef CONFIG_EFI_HANDOVER_PROTOCOL
 	.org 0x390
+#endif
 SYM_FUNC_START(efi64_stub_entry)
 	and	$~0xf, %rsp			/* realign the stack */
 	movq	%rdx, %rbx			/* save boot_params pointer */
diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index f912d777013052ea..d31982509654dcb1 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -406,7 +406,7 @@ xloadflags:
 # define XLF1 0
 #endif
 
-#ifdef CONFIG_EFI_STUB
+#ifdef CONFIG_EFI_HANDOVER_PROTOCOL
 # ifdef CONFIG_EFI_MIXED
 #  define XLF23 (XLF_EFI_HANDOVER_32|XLF_EFI_HANDOVER_64)
 # else
diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
index a3725ad46c5a0b49..bd247692b70174f0 100644
--- a/arch/x86/boot/tools/build.c
+++ b/arch/x86/boot/tools/build.c
@@ -290,6 +290,7 @@ static void efi_stub_entry_update(void)
 {
 	unsigned long addr = efi32_stub_entry;
 
+#ifdef CONFIG_EFI_HANDOVER_PROTOCOL
 #ifdef CONFIG_X86_64
 	/* Yes, this is really how we defined it :( */
 	addr = efi64_stub_entry - 0x200;
@@ -298,6 +299,7 @@ static void efi_stub_entry_update(void)
 #ifdef CONFIG_EFI_MIXED
 	if (efi32_stub_entry != addr)
 		die("32-bit and 64-bit EFI entry points do not match\n");
+#endif
 #endif
 	put_unaligned_le32(addr, &buf[0x264]);
 }
-- 
2.35.1


  parent reply	other threads:[~2022-11-22 16:12 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-22 16:10 [PATCH v3 00/17] x86: head_64.S spring cleaning Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 01/17] x86/compressed: efi-mixed: rename efi_thunk_64.S to efi-mixed.S Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Rename " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 02/17] x86/compressed: efi-mixed: move 32-bit entrypoint code into .text section Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 03/17] x86/compressed: efi-mixed: move bootargs parsing out of 32-bit startup code Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 04/17] x86/compressed: efi-mixed: move efi32_pe_entry into .text section Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 05/17] x86/compressed: efi-mixed: move efi32_entry out of head_64.S Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 06/17] x86/compressed: efi-mixed: move efi32_pe_entry() " Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 07/17] x86/compressed: efi: merge multiple definitions of image_offset into one Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed, efi: Merge " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 08/17] x86/compressed: efi-mixed: simplify IDT/GDT preserve/restore Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Simplify IDT/GDT preserve/restore in the EFI thunk tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 09/17] x86/compressed: avoid touching ECX in startup32_set_idt_entry() Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Avoid " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 10/17] x86/compressed: pull global variable ref up into startup32_load_idt() Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Pull global variable reference " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 11/17] x86/compressed: move startup32_load_idt() into .text section Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 12/17] x86/compressed: move startup32_load_idt() out of head_64.S Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 13/17] x86/compressed: move startup32_check_sev_cbit() into .text Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 14/17] x86/compressed: move startup32_check_sev_cbit() out of head_64.S Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Move " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 15/17] x86/compressed: adhere to calling convention in get_sev_encryption_bit() Ard Biesheuvel
2022-11-24  8:12   ` [tip: x86/boot] x86/boot/compressed: Adhere " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` [PATCH v3 16/17] x86/compressed: only build mem_encrypt.S if AMD_MEM_ENCRYPT=y Ard Biesheuvel
2022-11-24  8:11   ` [tip: x86/boot] x86/boot/compressed: Only " tip-bot2 for Ard Biesheuvel
2022-11-22 16:10 ` Ard Biesheuvel [this message]
2022-11-22 18:56   ` [PATCH v3 17/17] efi: x86: Make the deprecated EFI handover protocol optional Randy Dunlap
2022-11-24  8:11   ` [tip: x86/boot] x86/efi: " tip-bot2 for Ard Biesheuvel
2022-11-22 20:48 ` [PATCH v3 00/17] x86: head_64.S spring cleaning Tom Lendacky
2022-11-22 21:37   ` Ard Biesheuvel
2022-11-22 21:42     ` Ard Biesheuvel
2022-11-22 21:50       ` Tom Lendacky
2022-11-22 21:51         ` Ard Biesheuvel
2022-11-22 21:49     ` Tom Lendacky
2022-11-22 22:20       ` Borislav Petkov
2022-11-23 10:49       ` Borislav Petkov
2022-11-23 10:52         ` Ard Biesheuvel
2022-11-23 11:09           ` Borislav Petkov
2022-11-23 11:22             ` Ard Biesheuvel
2022-11-23 14:16           ` Tom Lendacky
2022-11-23 14:33             ` Ard Biesheuvel
2022-11-23 14:13         ` Tom Lendacky

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=20221122161017.2426828-18-ardb@kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.