Hi Stuart, The problem with implementing a driver for a specific TPM in BL1 is that you're stuck with that specific 3rd party TPM for life (or until the next tapeout). I would like to minimize the 3rd party drivers (outside the SOC) in BL1. Thanks, Ramon.
On Tue, May 31, 2022 at 6:30 PM Stuart Yoder stuart.yoder@arm.com wrote:
On 5/30/22 9:09 AM, Sandrine Bailleux via TF-A wrote:
Hello Ramon,
In my view, there are pros and cons for each of these solutions. Choosing the best design depends on the exact platform requirements.
Given that BL1 cannot be updated on your platform, you probably want to keep it as simple as possible to reduce the risk of introducing unpatchable bugs. If BL1 is responsible for measuring BL2 and writing this measurement into the I2C TPM, obviously it needs the measurement logic as well as some (potentially simplified) TPM driver. This might be undesirable, depending on how complex the TPM driver would be. -> This is solution 1 (BL1 measures BL2 and records the measurement in the TPM).
One additional note on this-- The TPM has a special, simple, hardware interface specifically designed for making this initial measurement. The interface avoids the need for a complicated driver or even having software compute the measurement.
The simplified BL1 driver could do: -write any data to TPM_HASH_START register -write the bytes of the image to be measured to TPM_HASH_DATA register -write any data to TPM_HASH_END register
That results in extending a measurement of the image into PCR0.
One thing to consider would be the performance of this interface. I don't know details of how long it takes, but it is slower than having the AP cores compute the haqsh.
Thanks, Stuart