TPM event log should not hardcode digest count in compile time

[carlosliu007]

Hi
We noticed that the digest count for the TPM event log is predefined at compile time. However, as far as I know, the active PCRs in TPM are configurable by the vendor through UEFI or TPM PPI in OS. Therefore, the digest count value should not be hardcoded in the source code.

See
https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/measured_boot/event_log/event_log.c

at line 41, 52, 74 and etc.

Do you have a plan to support dynamic value assignment for digests.count ?

Thanks
Carlos

[ManishVB-Arm]

Hi Carlos,

Thank you for raising this.

Initially, TPM support was not available in TF-A, but it is now in progress. We will explore how to dynamically provide the digest count and will get back to you with more details.

At first glance, it appears that the platform would need to communicate with the TPM to determine this digest count. If the platform does not support TPM and relies solely on the Event Log, then the platform would be responsible for providing this count.

[carlosliu007]

Hi
You can make a porting platform API which return the digest count and hash algorithm, the default stub implementation can return a digest count = 1 and hash algorithm is sha256
Carlos

[ManishVB-Arm]

Hi Carlos,

Indeed, it is necessary, and I initially thought the same. However, it’s not sufficient. We need to properly include measurements for all supported digest algorithms in the Event Log, which will require some design changes. This may also involve updating certain API signatures. It’s something that needs to be designed properly.
Possibly, during the Event Log initialization, the driver should stash information about the platform's supported algorithms and the algorithm count. This information can then be used to put the hashes in the Event Log records (e.g., during the generation of no-action events like locality events or post-code events such as measuring firmware components in the trusted chain, etc.).