[PATCH] x86/efi: Drop stale INITRD table entry on kexec boot

[Jaehee Park]

From: Jaehee Park <jpark@xxxxxxxxxxxxx>

The EFI stub allocates the INITRD configuration table in EFI_LOADER_DATA
memory. That memory can be reused after boot, but the configuration table
entry pointing to it survives kexec.

When a kexec'd kernel consumes the stale entry, efi_config_parse_tables()
clears the base and size fields at the old table address. If the new
initramfs occupies that memory, this overwrites 16 bytes of compressed
data and prevents the capture kernel from unpacking its initramfs.

Invalidate the INITRD entry when reusing the EFI configuration tables on
x86. Kexec supplies the new initrd through boot_params, so the capture
kernel does not need the old table.

Fixes: 6e62d1c6f2c7 ("efi: Wipe INITRD config table from memory after consumption")
Cc: stable@xxxxxxxxxxxxxxx
Signed-off-by: Jaehee Park <jpark@xxxxxxxxxxxxx>
---
Hi Ard, Sebastien,

I independently diagnosed and locally fixed this issue on October 6
while debugging kdump on an x86_64 L40S system. I was preparing to submit
my fix after internal review and found your October 12 proposal.

In my case, the stale INITRD table address overlapped the capture
initramfs. The capture kernel reported:

  Initramfs unpacking failed: ZSTD-compressed data is corrupt
  Failed to execute /init (error -2)
  Kernel panic - not syncing: No working init found.

My local fix invalidates the inherited INITRD entry in efi_reuse_config()
instead of changing the stub allocation. With that fix, the capture
initramfs checksum remained unchanged through successful unpacking and
kdump saved a crash dump.

The tested version also removed the data->smbios early return. I have
left that change out of this submission to keep the initial patch small.
This reduced version has not been boot-tested separately. It retains
the existing SMBIOS guard, so it does not cover SMBIOS3-only systems.
Would you prefer handling that guard as part of this fix?

Would invalidating the inherited entry also be useful when kexec boots
from a kernel whose stub allocated the table in EFI_LOADER_DATA? The
allocation change appears to address the lifetime at its source, while
this change prevents the incoming x86 kernel from consuming a stale
entry created by an older kernel.

I have not tested the ACPI reclaim patch, so I am not offering a
Tested-by for that patch.

Thanks,
Jaehee

 arch/x86/platform/efi/quirks.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/platform/efi/quirks.c b/arch/x86/platform/efi/quirks.c
--- a/arch/x86/platform/efi/quirks.c
+++ b/arch/x86/platform/efi/quirks.c
@@ -615,6 +615,13 @@
 		if (!efi_guidcmp(guid, EFI_MEMORY_ATTRIBUTES_TABLE_GUID))
 			((efi_config_table_64_t *)p)->table = EFI_INVALID_TABLE_ADDR;
 
+		/*
+		 * The EFI stub allocated this table in loader data, which may
+		 * have been reused. Kexec passes its initrd in boot_params.
+		 */
+		if (!efi_guidcmp(guid, LINUX_EFI_INITRD_MEDIA_GUID))
+			((efi_config_table_64_t *)p)->table = EFI_INVALID_TABLE_ADDR;
+
 		p += sz;
 	}
 	early_memunmap(tablep, nr_tables * sz);

base-commit: 7be4bc52fd9e0e55dc9a2e0232b89427d2c4b614
-- 
2.54.0