On 3/25/20 3:55 PM, Raghu Krishnamurthy wrote:
Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else.
In the case of TPM measured boot, you still have to have an event log which also contains the PCR, measurement, and metadata. So, even if BL1/2 record measurements directly into the TPM an event log has to be passed forward to UEFI and the OS.
So, a mechanism is needed to pass the event log forward, and the DTB is being used for that.
The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB.
I thought that the API to extend measurement was platform specific, and so the part of TF-A making the measurements was abstracted away from the underlying implementation which should be platform specific. I'll let Alexei comment further.
It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
My take on this was that the TCG event log, held in secure memory, has all the information needed to enable an SEL0/1 component transfer the measurements into the physical PCRs. Just pass the event log to SEL0/1 and it can replay the measurements into the TPM.
You have to have the event log anyway, so why would using a second mechanism like virtual PCRs to hold measurements help?
Thanks, Stuart