On 10/29/20 4:23 PM, raghu.ncstate@icloud.com wrote:

Thanks for the link Ruchika.

 

>> Case 1.  Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow.

In my view, this is where ARM platforms should be heading to rather than waiting for the TPM app to load, parse event log from secure memory and then extend measurements into the TPM. The CRTM starts getting too large at this point and a single exploit in any code executing after BL1 would make measured boot less reliable. Note that this model of extending measurements later creates dependency on having secure boot for BL2, BL31 etc. Ideally measured boot and secure boot are independent security features providing different properties.

 

Agree with Raghu that it is preferred to have the entities doing the measurement extend them into the TPM.  The greater the window of time between measurement and storing in the TPM the more risk.

>> Case 2.  If BL1 and BL2 don't have the TPM driver as mentioned in  Case 1 above, who would be responsible for extending the measurements for secure world entities.

See page 21 of https://developer.arm.com/documentation/den0086/latest.  It should answer both questions. SBSG says that the TPM driver can be a part of Secure EL0 and since the S-EL0 partition/driver is not up yet during early boot(bl1, bl2, bl31, bl32 etc), it is permissible for these stages to record measurements in secure memory and have it replayed to the TPM once secure EL0 is up. The TPM driver/S-EL0 app should own the TPM and its physical bus and should provide an SMC interface for UEFI to use to continue extending measurements. This is my understanding of what is done today by TF-A.

 

Stuart, SBSG says “It is acceptable for the first mutable firmware component to measure itself because it has been verified by the immutable bootloader and is then trusted.”. I would suggest that you strongly recommend extending first mutable code measurements in immutable code to the TPM, in SBSG. This may have been acceptable a few years ago but in all likelihood will not be acceptable in the near future.

 

If it's feasible for the bootrom to make measurements into the TPM that would be ideal.  Since this is in ROM which is fixed in the SoC prior to tape out there could be challenges depending on how the TPM is integrated into the system-- things like which SPI chip select to assert, etc.  It means needing a SPI/I2C controller driver, minimal TPM driver, etc.

Thanks,
Stuart