[RFC] efi/tpm: ACPI reclaim event log allocation breaks x86 hibernation

[RFC] efi/tpm: ACPI reclaim event log allocation breaks x86 hibernation

[Jasmeet (Jazz) Bhatia]

Hello,

This is my first mail to the Linux mailing lists, so apologies
if I've missed any conventions.

I have been investigating a reproducible x86 hibernation resume
failure and have traced it to the EFI stub's TPM event log allocation.

The system is a Framework Laptop 16 (AMD Ryzen AI 300 Series), using
Insyde UEFI 2.9 / Framework BIOS 04.01.

On resume, the hibernation image is found, but x86 eventually rejects
it because the firmware E820 map does not match:

    PM: Image signature found, resuming
    PM: hibernation: resume from hibernation
    ...
    PM: Loading and decompressing image data (4198398 pages)...
    Hibernate inconsistent memory map detected!
    PM: hibernation: Image mismatch: architecture specific data
    PM: Error -1 resuming
    PM: hibernation: Failed to load image, recovering.
    PM: hibernation: resume failed (-1)

I compared the E820 map across repeated ordinary boots and found a
48 KiB ACPI data region whose address changes from boot to boot. Its
base always corresponds to the TPMEventLog EFI configuration table
address (the table pointer is base + 0x18).

For example, across five ordinary boots:

    E820 ACPI data region          TPMEventLog
    678da000-678e5fff              678da018
    678db000-678e6fff              678db018
    678d1000-678dcfff              678d1018
    678d6000-678e1fff              678d6018
    678d8000-678e3fff              678d8018

This occurs on normal reboots as well, so it doesn't seem to be
specific to an S4 firmware path.

drivers/firmware/efi/libstub/tpm.c currently allocates the copied TPM
event log using EFI_ACPI_RECLAIM_MEMORY:

    status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY,
                         sizeof(*log_tbl) + log_size,
                         (void **)&log_tbl);

As a diagnostic experiment, I changed only the memory type back to
EFI_LOADER_DATA:

-   status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY,
+   status = efi_bs_call(allocate_pool, EFI_LOADER_DATA,
                         sizeof(*log_tbl) + log_size,
                         (void **)&log_tbl);

With that change, TPMEventLog continues to move between boots, e.g.

    boot 1: TPMEventLog=0x678d8018
    boot 2: TPMEventLog=0x678d5018

but the BIOS-e820 entries are identical across those boots. The
48 KiB ACPI data island around TPMEventLog is no longer present.

Most importantly, Linux 7.2.0 with only this one-line diagnostic
change successfully hibernates and resumes, whereas the unmodified
7.2.0 kernel fails to resume.

Despite that, I don't think simply reverting to EFI_LOADER_DATA is a
good fix. Looking back, I noticed commit 77d48d39e991
("efistub/tpm: Use ACPI reclaim memory for event log to avoid
corruption") intentionally moved away from this allocation to prevent
the TPM event log from appearing as unreserved RAM to an incoming
kexec kernel.

I tried retaining EFI_LOADER_DATA while registering the TPM log with
efi_mem_reserve_persistent(). The ordinary memblock reservation
protects it in the running kernel, and I hoped the persistent EFI
reservation could provide the kexec protection without changing E820.

On x86, however, efi_mem_reserve_persistent() returned -ENODEV:

    Failed to persistently reserve TPM Event Log: -19

Looking at current mainline, the Linux EFI MEMRESERVE root is installed
by install_memreserve_table() via efi_stub_common(), while x86 uses its
own stub path. Current master (abdf623dd) also still allocates the TPM
event log as EFI_ACPI_RECLAIM_MEMORY.

At this point I'm a little unsure what the correct approach to fixing
this is, so I would appreciate guidance on where the fix should live.

Should the TPM event log remain EFI_ACPI_RECLAIM_MEMORY and x86
hibernation account for this Linux-created, boot-dependent E820 entry?

Or is there an existing/preferred x86 mechanism for preserving an
EFI_LOADER_DATA TPM event log across kexec without making the transient
allocation part of the firmware E820 topology?

I have the full failed-resume dmesg, before/after E820 maps, five
ordinary-boot maps, and the successful diagnostic hibernation logs,
and I can provide any additional testing that would be useful.

Thanks,
Jasmeet Bhatia

Re: [RFC] efi/tpm: ACPI reclaim event log allocation breaks x86 hibernation

[Ard Biesheuvel]

(cc Breno)

Hi Jazz,

On Tue, 1 Sep 2026, at 04:34, Jasmeet (Jazz) Bhatia wrote:
> Hello,
>
> This is my first mail to the Linux mailing lists, so apologies
> if I've missed any conventions.
>
> I have been investigating a reproducible x86 hibernation resume
> failure and have traced it to the EFI stub's TPM event log allocation.
>
> The system is a Framework Laptop 16 (AMD Ryzen AI 300 Series), using
> Insyde UEFI 2.9 / Framework BIOS 04.01.
>
> On resume, the hibernation image is found, but x86 eventually rejects
> it because the firmware E820 map does not match:
>
>     PM: Image signature found, resuming
>     PM: hibernation: resume from hibernation
>     ...
>     PM: Loading and decompressing image data (4198398 pages)...
>     Hibernate inconsistent memory map detected!
>     PM: hibernation: Image mismatch: architecture specific data
>     PM: Error -1 resuming
>     PM: hibernation: Failed to load image, recovering.
>     PM: hibernation: resume failed (-1)
>
> I compared the E820 map across repeated ordinary boots and found a
> 48 KiB ACPI data region whose address changes from boot to boot. Its
> base always corresponds to the TPMEventLog EFI configuration table
> address (the table pointer is base + 0x18).
>
> For example, across five ordinary boots:
>
>     E820 ACPI data region          TPMEventLog
>     678da000-678e5fff              678da018
>     678db000-678e6fff              678db018
>     678d1000-678dcfff              678d1018
>     678d6000-678e1fff              678d6018
>     678d8000-678e3fff              678d8018
>
> This occurs on normal reboots as well, so it doesn't seem to be
> specific to an S4 firmware path.
>
> drivers/firmware/efi/libstub/tpm.c currently allocates the copied TPM
> event log using EFI_ACPI_RECLAIM_MEMORY:
>
>     status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY,
>                          sizeof(*log_tbl) + log_size,
>                          (void **)&log_tbl);
>
> As a diagnostic experiment, I changed only the memory type back to
> EFI_LOADER_DATA:
>
> -   status = efi_bs_call(allocate_pool, EFI_ACPI_RECLAIM_MEMORY,
> +   status = efi_bs_call(allocate_pool, EFI_LOADER_DATA,
>                          sizeof(*log_tbl) + log_size,
>                          (void **)&log_tbl);
>
> With that change, TPMEventLog continues to move between boots, e.g.
>
>     boot 1: TPMEventLog=0x678d8018
>     boot 2: TPMEventLog=0x678d5018
>
> but the BIOS-e820 entries are identical across those boots. The
> 48 KiB ACPI data island around TPMEventLog is no longer present.
>
> Most importantly, Linux 7.2.0 with only this one-line diagnostic
> change successfully hibernates and resumes, whereas the unmodified
> 7.2.0 kernel fails to resume.
>
> Despite that, I don't think simply reverting to EFI_LOADER_DATA is a
> good fix. Looking back, I noticed commit 77d48d39e991
> ("efistub/tpm: Use ACPI reclaim memory for event log to avoid
> corruption") intentionally moved away from this allocation to prevent
> the TPM event log from appearing as unreserved RAM to an incoming
> kexec kernel.
>

There might be other ways to protect this memory from being clobbered
by kexec.

Or even better, given that both hibernate and kexec invalidate the
TPM attestation trail anyway, perhaps it would be better to simply
find a way for kexec to ignore this table altogether. That way, we
could use EFI_LOADER_DATA for the region, and your issue goes away.

-- 
Ard.


(leaving untrimmed below)

> I tried retaining EFI_LOADER_DATA while registering the TPM log with
> efi_mem_reserve_persistent(). The ordinary memblock reservation
> protects it in the running kernel, and I hoped the persistent EFI
> reservation could provide the kexec protection without changing E820.
>
> On x86, however, efi_mem_reserve_persistent() returned -ENODEV:
>
>     Failed to persistently reserve TPM Event Log: -19
>
> Looking at current mainline, the Linux EFI MEMRESERVE root is installed
> by install_memreserve_table() via efi_stub_common(), while x86 uses its
> own stub path. Current master (abdf623dd) also still allocates the TPM
> event log as EFI_ACPI_RECLAIM_MEMORY.
>
> At this point I'm a little unsure what the correct approach to fixing
> this is, so I would appreciate guidance on where the fix should live.
>
> Should the TPM event log remain EFI_ACPI_RECLAIM_MEMORY and x86
> hibernation account for this Linux-created, boot-dependent E820 entry?
>
> Or is there an existing/preferred x86 mechanism for preserving an
> EFI_LOADER_DATA TPM event log across kexec without making the transient
> allocation part of the firmware E820 topology?
>
> I have the full failed-resume dmesg, before/after E820 maps, five
> ordinary-boot maps, and the successful diagnostic hibernation logs,
> and I can provide any additional testing that would be useful.
>
> Thanks,
> Jasmeet Bhatia