Hi Alexei,

Thanks. This looks good at first glance. However, i do have some questions that aren't obvious to me by reading the description below and looking at code. Questions are numbered based on your original email. Perhaps these can be discussed in the TF-A forum if it is inconvenient over email.

1) Would be good if the hash alg comes from the config file. This will make the implementation "crypto agile" from the very beginning. It is common to want to upgrade/change the hash algorithm and since BL1 is in ROM, you potentially break measured boot on old devices in case a hash algorithm is broken. The other option is to get the hash algorithm from the platform, perhaps a platform gets it from eFuses as opposed to config files. 2) It looks like you are using memory allocated in the loaded DTB as the equivalent of a TPM "PCR". How is this protected from direct modification by BL2? Or is it not protected because BL2 forms a part of the Root-of-Trust for Measurement(RTM)?(since it's signature is verified by BL1?) 3) What does "Event Log" refer to? Is it the same event log proposed by TCG in the platform firmware profile ? As a general question, how close is the measured boot in TF-A/PSA going to be to TCG ? Will BL2 extend measurements for other images ? 4) Would be great not to refer to "TPM" in the measured boot implementation. Here we are implementing measured boot without a TPM, but it could be implemented with a TPM. Maybe it should be tcg event log? 5) OK. 6) What does validate event log mean here? More details ?

Thanks -Raghu

On 3/20/20 7:15 AM, Alexei Fedorov via TF-A wrote:

Hello,

I'm preparing the next set of patches for Measured Boot support in TF-A, please find some details on design and implementation below.

1. SHA256/384/512 hash algorithm for Measured Boot related hash calculations

is passed as an existing build 'HASH_ALG' build parameter.

2. BL1 calculates BL2 image hash and passes these data to BL2 via

FW_CONFIG/TB_FW_CONFIG device tree in new 'bl2_hash_data' byte array added    in 'fvp_fw_config.dts'.

These changes are part of the patch under review, please see    https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3555

3. Event Log is calculated by BL2 in Secure Memory and copied to

Non-secure memory. Address in Non-secure memory is calculated as:

"nt_fw_config_addr + nt_fw_config_max_size"

with values obtained from 'tb_fw_config':

nt_fw_config_addr = <0x0 0x80000000>;      nt_fw_config_max_size = <0x200>;

4. Event Log address and size is passed by TOS_FW_CONFIG and NT_FW_CONFIG

device tree in 2 new added properties:

Property name:  'tpm_event_log_addr'    Value type is an unsigned 64-bit integer specifying the physical address    of the Event Log.

Property name:  'tpm_event_log_size'    Value type is an unsigned 32-bit integer specifying the size of the Event Log.

/* TPM Event Log Config */    tpm_event_log {        compatible = "arm,nt_fw";        tpm_event_log_addr = <0x0 0x0>;        tpm_event_log_size = <0x0>;    };

5. TF-A provides Event Log to the BL33 (TFTF/UEFI/U-boot) in 'nt_fw_config'

device tree, which address is passed by BL31 as 'arg0' parameter, see TFTF patch:

https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/3327

6. A new test which validates and prints Event Log data passed

in 'nt_fw_config' to BL33 will be added to TFTF.

Please review and provide your comments on the proposed design.

Regards. Alexei.

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.