Re: [PATCH v1 0/2] efi/tpm: Preserve event log without changing x86 E820
From: Ard Biesheuvel
Date: Fri Sep 04 2026 - 13:16:34 EST
On Fri, 4 Sep 2026, at 17:45, Jasmeet (Jazz) Bhatia wrote:
> On Thu Sep 3, 2026 at 7:18 AM PDT, Ard Biesheuvel wrote:
>> Hi Jazz,
>>
>> On Tue, 1 Sep 2026, at 13:34, Jasmeet (Jazz) Bhatia wrote:
>>> The EFI stub currently allocates the TPM event log as
>>> EFI_ACPI_RECLAIM_MEMORY. On x86, this becomes an ACPI data entry
>>> in the E820 map.
>>>
>>> On a Framework Laptop 16 (AMD Ryzen AI 300 Series), the EFI allocator
>>> can place this allocation at different physical addresses across boots.
>>> Since x86 hibernation validates architecture-specific data from
>>> the firmware E820 map, this causes an otherwise valid hibernation image
>>> to be rejected on resume with the following error:
>>>
>>> Hibernate inconsistent memory map detected!
>>> PM: hibernation: Image mismatch: architecture specific data
>>>
>>> Allocating the event log as EFI_LOADER_DATA avoids changing the E820
>>> map, but doing that alone would regress the kexec corruption issue fixed
>>> by commit 77d48d39e991 ("efistub/tpm: Use ACPI reclaim memory for event
>>> log to avoid corruption").
>>>
>>
>> As I replied in the other thread, I am not convinced preserving the TPM
>> event log across a kexec makes sense to begin with. This is the firmware's
>> view of the state of the TPM PCRs when it handed over the system to the
>> first OS.
>>
>> If the first OS boots, loads a kexec kernel and then boots it without
>> measuring any of that into the TPM, the TPM event log will match the
>> TPM state, but this is meaningless because of the missing measurements,
>> and the attestation chain is broken.
>>
>> If the first OS does perform TPM measurements, it would need to record
>> them into a log and pass that on to the kexec'ed in some implementation
>> specific way - it cannot use the existing TPM event log for that.
>>
>> TL;DR perhaps we should just discard the TPM event log reference from
>> the EFI config tables after consuming it. Or add a special case to the
>> kexec code to disregard it.
> Ok, honestly that makes a lot of sense I see what you are saying and I
> tend to agree. I'm treating the copied event log at something that
> survives kexec in this patch because of the corruption fix so I'll look
> at dropping that LINUX_EFI_TPM_EVENT_LOG_GUID reference and rewrite this
> patch. Hopefully, that will avoid that x86 E820 instability as well.
>
> Appreciate the guidance!
Please don't send any patches yet - I'd like to get some input from other
folks as well.