Linux Power Management development
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: "Jasmeet (Jazz) Bhatia" <jasmeet.bhatia.us@gmail.com>
Cc: "Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	"Pavel Machek" <pavel@ucw.cz>,
	linux-efi@vger.kernel.org, linux-pm@vger.kernel.org,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 0/2] efi/tpm: Preserve event log without changing x86 E820
Date: Fri, 04 Sep 2026 18:38:28 +0200	[thread overview]
Message-ID: <c3ca811b-a6eb-4f4d-bbb2-4feef02e3db2@app.fastmail.com> (raw)
In-Reply-To: <DL6NCV1KQ9F9.6K6XZQCS4AF3@gmail.com>



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.


      reply	other threads:[~2026-09-04 16:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01 11:34 [PATCH v1 0/2] efi/tpm: Preserve event log without changing x86 E820 Jasmeet (Jazz) Bhatia
2026-09-01 11:34 ` [PATCH v1 1/2] efi/libstub: Install memreserve table on x86 Jasmeet (Jazz) Bhatia
2026-09-01 11:34 ` [PATCH v1 2/2] efi/tpm: Persistently reserve the TPM event log Jasmeet (Jazz) Bhatia
2026-09-03 14:18 ` [PATCH v1 0/2] efi/tpm: Preserve event log without changing x86 E820 Ard Biesheuvel
2026-09-04 15:45   ` Jasmeet (Jazz) Bhatia
2026-09-04 16:38     ` Ard Biesheuvel [this message]

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=c3ca811b-a6eb-4f4d-bbb2-4feef02e3db2@app.fastmail.com \
    --to=ardb@kernel.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=jasmeet.bhatia.us@gmail.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=x86@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox