Hello Stuart, Alexei,

Chiming-in here on Ampere's behalf...

We analysed this proposal internally. And we see a number issues with this, some of which was already raised by Raghu in the previous threads.

Here is a summary of the main issues that we see.

We propose that there should be a variable for the algorithm to be used, which can be setup at initialization time.

This solution relies on taking the hash directly from the digest as the measurement, instead of the computed hash. This is not safe, especially considering measured boot may use a different hash bank, so digest hash may not be correct/valid.
Only measuring the BL2 image, per the ARM SBSG we must be measuring and logging *all* images/boot phases

Once we ERET into BL33, the measure boot flow continues and is owned by that boot loader

Only see support for PCR0, any/all unsigned config data must be logged to PCR1.
Passing PCRs to non-secure software before logging is not compliant with TCG Static-Root-of-Trust Measurement (SRTM) requirements

It was discussed before in separate conversations… especially in systems where you are talked about two different signing domains where BL33 is a different trust/signing domain.
BL33 should only do hash-log-extend… there is no need for BL33 to be aware of the current PCR value (beyond what is provided in the boot event log).

Based on comments on the mail thread, there seem to be bad assumptions/expectations around TPM accessibility from non-secure world.

Expecting SPI/I2C TPMs to be directly accessed from non-secure world instead of abstracting hardware details via the TCG CRB interface (which has been already standardized as the defacto mechanism for ARM on past mobile, client, and server solutions).
CRB will "just work" for Aptio/EDK2/Linux/Windows/Hyper-V/VMWare
NOTE: This goes back to what is a “productizable” TPM solution. We want it to be turn-key solution for customers without having to support/develop proprietary drivers.