This is a note to let you know that I've just added the patch titled
x86/efistub: Reinstate soft limit for initrd loading
to the 6.7-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
x86-efistub-reinstate-soft-limit-for-initrd-loading.patch
and it can be found in the queue-6.7 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From decd347c2a75d32984beb8807d470b763a53b542 Mon Sep 17 00:00:00 2001
From: Ard Biesheuvel <ardb@xxxxxxxxxx>
Date: Thu, 28 Mar 2024 15:49:48 +0100
Subject: x86/efistub: Reinstate soft limit for initrd loading
From: Ard Biesheuvel <ardb@xxxxxxxxxx>
commit decd347c2a75d32984beb8807d470b763a53b542 upstream.
Commit
8117961d98fb2 ("x86/efi: Disregard setup header of loaded image")
dropped the memcopy of the image's setup header into the boot_params
struct provided to the core kernel, on the basis that EFI boot does not
need it and should rely only on a single protocol to interface with the
boot chain. It is also a prerequisite for being able to increase the
section alignment to 4k, which is needed to enable memory protections
when running in the boot services.
So only the setup_header fields that matter to the core kernel are
populated explicitly, and everything else is ignored. One thing was
overlooked, though: the initrd_addr_max field in the setup_header is not
used by the core kernel, but it is used by the EFI stub itself when it
loads the initrd, where its default value of INT_MAX is used as the soft
limit for memory allocation.
This means that, in the old situation, the initrd was virtually always
loaded in the lower 2G of memory, but now, due to initrd_addr_max being
0x0, the initrd may end up anywhere in memory. This should not be an
issue principle, as most systems can deal with this fine. However, it
does appear to tickle some problems in older UEFI implementations, where
the memory ends up being corrupted, resulting in errors when unpacking
the initramfs.
So set the initrd_addr_max field to INT_MAX like it was before.
Fixes: 8117961d98fb2 ("x86/efi: Disregard setup header of loaded image")
Reported-by: Radek Podgorny <radek@xxxxxxxxxxx>
Closes: https://lore.kernel.org/all/a99a831a-8ad5-4cb0-bff9-be637311f771@xxxxxxxxxxx
Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
drivers/firmware/efi/libstub/x86-stub.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/firmware/efi/libstub/x86-stub.c
+++ b/drivers/firmware/efi/libstub/x86-stub.c
@@ -487,6 +487,7 @@ efi_status_t __efiapi efi_pe_entry(efi_h
hdr->vid_mode = 0xffff;
hdr->type_of_loader = 0x21;
+ hdr->initrd_addr_max = INT_MAX;
/* Convert unicode cmdline to ascii */
cmdline_ptr = efi_convert_cmdline(image, &options_size);
Patches currently in stable-queue which might be from ardb@xxxxxxxxxx are
queue-6.7/x86-efistub-reinstate-soft-limit-for-initrd-loading.patch
queue-6.7/efi-libstub-cast-away-type-warning-in-use-of-max.patch
queue-6.7/x86-kconfig-remove-config_amd_mem_encrypt_active_by_default.patch
queue-6.7/efi-fix-panic-in-kdump-kernel.patch
queue-6.7/init-kconfig-lower-gcc-version-check-for-warray-bounds.patch
queue-6.7/x86-efistub-add-missing-boot_params-for-mixed-mode-compat-entry.patch
queue-6.7/arm-9352-1-iwmmxt-remove-support-for-pj4-pj4b-cores.patch
queue-6.7/x86-sev-fix-position-dependent-variable-references-in-startup-code.patch
queue-6.7/efi-libstub-fix-efi_random_alloc-to-allocate-memory-.patch
queue-6.7/x86-efistub-call-mixed-mode-boot-services-on-the-firmware-s-stack.patch
