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

[Ludwig Nussel]

On 6/15/26 13:38, Ilias Apalodimas wrote:
> 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.

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 :-)

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 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?

The elog parameters of tcg2_log_prepare_buffer() and tcg2_measure_data() 
are not related to the dev parameter. So it looks like the intention is 
to be able to call it on the same tpm but with different event logs.

cu
Ludwig

-- 
Ludwig Nussel
Siemens AG
www.siemens.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: efi-use-tcg2_measurement_init.diff
Type: text/x-patch
Size: 3211 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260615/5729bdd8/attachment.bin>