Hi,

Thank you Stuart for the detailed explanation of the basis of the design considirations for Measured Boot/Event Log.
Radhu, thanks for all your inputs and the proposed changes for the current design which are much appreciated.
I would suggest that for now it would be practical to go ahead with the current FVP platform specific implementation of the Measured Boot which we could modify later in case of any new requirements and change request arise.
For the making the crypto algorithm used data driven through platform configuration/eFuses
I'm thinking of providing a new function with API which would set TCG hash algoritm based on
the build option, configuration or values read from eFuses. Please share your thoughts on that.

Regards.
Alexei

From: Raghu Krishnamurthy <raghu.ncstate@icloud.com>
Sent: 25 March 2020 22:47
To: Stuart Yoder <Stuart.Yoder@arm.com>; Alexei Fedorov <Alexei.Fedorov@arm.com>; tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: Re: [TF-A] Proposal for Measured Boot Implementation
 
> You have to have the event log anyway, so why would using a second
 > mechanism like
 > virtual PCRs to hold measurements help?
The event log can be used like you say, in the case where there is a
later point in boot time such as SEL0/SEL1 or whatever talks to the
fTPM/dTPM, transfers it over to the physical PCR's. In this case, you
don't really need virtual PCR's. It can perhaps be used as a debug
mechanism to verify what is being written into the physical PCR matches
your virtual PCR(suppose there is a bug in parsing event log) and for
logging the expected PCR values at different stages of boot. The
implementation will also look the same in that you always invoke the
platform hook to extend PCR's, as would be the case where you are
extending measurements to a physical PCR as you boot(ie in BL1, BL2, BLX
etc), except that the platform hook will be empty or print the value or
record the measurement into a virtual PCR.


Thanks
Raghu

On 3/25/20 3:21 PM, Stuart Yoder wrote:
>
>
> 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
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.