[PATCH v2 3/3] tpm: allocate tpm event log if missing
Ilias Apalodimas
ilias.apalodimas at linaro.org
Mon Jun 15 13:38:22 CEST 2026
Hi Ludwig,
On Mon, 15 Jun 2026 at 13:10, Ludwig Nussel <ludwig.nussel at siemens.com> wrote:
>
> On 6/11/26 11:57, Ilias Apalodimas wrote:
> > [...]
> > On Wed, 10 Jun 2026 at 13:52, Ludwig Nussel <ludwig.nussel at siemens.com> wrote:
> > [...]
> >> if (IS_ENABLED(CONFIG_MEASURED_BOOT)) {
> >> - struct tcg2_event_log elog;
> >> struct udevice *dev;
> >> void *initrd_buf;
> >> void *image_buf;
> >> const char *s;
> >> u32 rd_len;
> >> - bool ign;
> >>
> >> - elog.log_size = 0;
> >> - ign = IS_ENABLED(CONFIG_MEASURE_IGNORE_LOG);
> >> - ret = tcg2_measurement_init(&dev, &elog, ign);
> >> - if (ret)
> >> + ret = tcg2_measurement_init(&dev, NULL);
> >
> > 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.
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.
> I am not sure what the intention of the current api is tbh. The event
> log basically documents when and how PCR registers were extended. We
> have to build that log ourselves as the TPM doesn't do it for us. The
> api weirdly allows to have partial local logs even though there's only
> one set of PCR registers.
Where?
>
> >> [...]
> >> index d41228f75a9..2270b038cf5 100644
> >> --- a/lib/tpm_tcg2.c
> >> +++ b/lib/tpm_tcg2.c
> >> @@ -21,6 +21,7 @@
> >> #include <linux/unaligned/le_byteshift.h>
> >> #include "tpm-utils.h"
> >> #include <bloblist.h>
> >> +#include <dm/devres.h>
> >>
> >> int tcg2_get_pcr_info(struct udevice *dev, u32 *supported_bank, u32 *active_bank,
> >> u32 *bank_num)
> >> @@ -212,6 +213,9 @@ static int tcg2_log_append_check(struct tcg2_event_log *elog, u32 pcr_index,
> >> u32 event_size;
> >> u8 *log;
> >>
> >> + if (!elog || !elog->log_size)
> >> + return 0;
> >> +
> >> event_size = size + tcg2_event_get_size(digest_list);
> >> if (elog->log_position + event_size > elog->log_size) {
> >> printf("%s: log too large: %u + %u > %u\n", __func__,
> >> @@ -553,6 +557,9 @@ int tcg2_measure_data(struct udevice *dev, struct tcg2_event_log *elog,
> >> if (rc)
> >> return rc;
> >>
> >> + if (!elog)
> >> + elog = tcg2_platform_get_dev_log(dev);
> >> +
> >
> > Initializing this here feels wrong. This is a function that just
> > measures and logs data. Why can't we fill in the eventlog address
> > early before calling this? If we do so some of the checks above are
> > also not needed
>
> tcg2_platform_get_dev_log() is just a wrapper to access the private
> property of dev that keeps the event log address.
> How about moving the call into tcg2_log_append_check() instead?
I am ok moving the EventLog pointer as part of the TPM device. But I
think this should be part of tcg2_prepare_log_buffer(). That way it
will propagate to the EFI code easily.
>
> cu
> Ludwig
>
[1] https://source.denx.de/u-boot/custodians/u-boot-tpm/-/tree/unify_tcg2
Cheers
/Ilias
> --
> Ludwig Nussel
> Siemens AG
> www.siemens.com
More information about the U-Boot
mailing list