[PATCH v2 3/3] tpm: allocate tpm event log if missing

Ilias Apalodimas ilias.apalodimas at linaro.org
Tue Jun 16 12:32:44 CEST 2026


On Tue, 16 Jun 2026 at 12:39, Ludwig Nussel <ludwig.nussel at siemens.com> wrote:
>
> On 6/15/26 15:25, Ilias Apalodimas wrote:
> > On Mon, 15 Jun 2026 at 16:09, Ilias Apalodimas
> > <ilias.apalodimas at linaro.org> wrote:
> >>
> >> Hi Ludwig,
> >>
> >> [...]
> >>
> >>>>>>
> >>>>>> I'd like the eventlog to be initialized before calling this (look below).
> >>>>>
> >>>>> What if I removed the log parameter from those tcg2_* functions instead?
> >>>>> The event log belongs to the tpm device IMO, so should be initialized
> >>>>> with the device.
> >>>>
> >>>> Measured boot EventLogs etc are primarily described by the TCG specs &
> >>>> EFI and we only have a specification for it there. The DT describes on
> >>>> how to pass it over to linux with sml-base etc.
> >>>> However, in the EFI case the Eventlog is allocated as ACPI memory. So
> >>>> you cannot allocate the EventLog a priori, until you figure out what
> >>>> method you are using to boot. We also have use cases people using it
> >>>> only for RNG, due to limited memory, so we can't just allocate it on
> >>>> the device bringup. And lastly... Some first stage bootloaders do not
> >>>> initialize the TPM & drivers. What they do is prepare an EventLog and
> >>>> expect U-Boot to replay it once the TPM is up and running. In that
> >>>> case we obviously need to preserve what we have instead of starting
> >>>> from scratch.
> >>>
> >>> Ack, we are on the same page here.
> >>>
> >>>> My main concern is that I *don't* want the EFI and non-EFI code to
> >>>> deviate. I have some patches that I am playing around for quite some
> >>>> time and rebased them last week for this reason [1]. If you think
> >>>> those help your use case or make your life easier feel free to include
> >>>> them.
> >>>
> >>> Good idea and orthogonal to what I am doing I think. This duplication in
> >>> EFI stressed my brain too but I can't care about EFI right now :-)
> >>
> >> It is, but the deviation in EFI is pretty minimal atm.
> >> - EFI calls tcg2_log_prepare_buffer instead of tcg2_measurement_init()
> >> -- That's what my patches fix
> >> - EFI has it's own version of tcg2_measure_event() -- That's easy to
> >> fix as well,.
> >>
> >>>
> >>> IIUC you are centering the change around calling
> >>> tcg2_log_prepare_buffer() in efi_init_event_log(). What do you think
> >>> about aiming for tcg2_measurement_init() as central starting point
> >>> instead?
> >>> That would allow to remove even more duplicated code.
> >>> It should be sufficient to have tcg2_measurement_init() accept an
> >>> optional pointer to pre-allocated log buffer memory. Attached patch
> >>> maybe explains the idea better (just as idea, won't compile).
> >>
> >> I agree. In fact I mistyped the functions names on my previous
> >> email.... I really meant tcg2_measurement_init(). The patchset I
> >> pointed you to already converts tcg2_log_prepare_buffer() to static.
> >
> > Replying to myself here, but.. In order to do that you do need the
> > unification patches. tcg2_measurement_init() will need to allocate the
> > appropriate buffer depending on EFI or not.
>
> So this is how it would look like with your patches on top:
> https://github.com/u-boot/u-boot/compare/master...lnussel:u-boot:tpm-with-ilias-patches
>
> IMO the untangle patch is not needed. Does that look sensible?

You can skip the untangle patch the way you've changed efi_tcg2.c, that's fine.

However, there's a few issues I tested for
- A u32 err; that's not needed in EFI anymore
- tcg2_measurement_init() calls tcg2_log_prepare_buffer, with NULL. I
suspect you meant to call with elog, since the EFI booting is now
broken and the kernel complains about an incomplete EventLog
([Firmware Bug]: Failed to parse event in TPM Final Events Log). But
since we've gone through that effort, wouldn't it make more sense to
have tcg2_measurement_init() set the priv->log if the pointer is valid
and provided?

/Ilias
>
> cu
> Ludwig
>
> --
> Ludwig Nussel
> Siemens AG
> www.siemens.com


More information about the U-Boot mailing list