[PATCH v2 3/3] tpm: allocate tpm event log if missing
Ilias Apalodimas
ilias.apalodimas at linaro.org
Tue Jun 16 13:46:35 CEST 2026
On Tue, 16 Jun 2026 at 14:06, Ludwig Nussel <ludwig.nussel at siemens.com> wrote:
>
> On 6/16/26 12:32, Ilias Apalodimas wrote:
> > 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:
> >> [...]
> >>
> >> 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
>
> Oops. Yes, that was a mistake.
>
> > [...] 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?
>
> Yes, the series paves the way for further refactoring :-) The efi path
> shouldn't have the 'static struct tcg2_event_log event_log' anymore IMO.
> Should be sufficient to hand the allocated buffer to
> tcg2_measurement_init() and access the log structure in functions that
> need it though 'dev'.
Exactly.
> Refactoring (and testing) the EFI path is out of
> scope for me at the moment though.
Fair enough, I've sidetracked you enough already.
>
> Anyway, do you want me to submit your two patches as part of the series
> or you want to follow up yourself?
Carry them over imho, they were rotting in my branches for 1+ years,
but I never had the chance to send them. Your patches were a good
reason to rebase and revive them and they fit right in as can only
rely on tcg2_measurement_init now. I'll test/check the v4. I haven't
gone through your changes in depth but they seemed reasonable, so I
think this is fairly close on getting in
Thanks for the patience
/Ilias
>
> cu
> Ludwig
>
> --
> Ludwig Nussel
> Siemens AG
> www.siemens.com
More information about the U-Boot
mailing list