+Harb

________________________________ From: TF-A tf-a-bounces@lists.trustedfirmware.org on behalf of Vivek Prasad via TF-A tf-a@lists.trustedfirmware.org Sent: Thursday, April 16, 2020 10:19 AM To: Stuart Yoder stuart.yoder@arm.com; Alexei Fedorov Alexei.Fedorov@arm.com; tf-a tf-a@lists.trustedfirmware.org; Raghu Krishnamurthy raghu.ncstate@icloud.com Cc: Loc Ho loc.ho@amperecomputing.com; Vivek Kumar vivek@amperecomputing.com; Benjamin Chaffin bchaffin@amperecomputing.com; Ard Biesheuvel Ard.Biesheuvel@arm.com; Mohamad Ammar moe@amperecomputing.com; Charles Garcia-Tobin Charles.Garcia-Tobin@arm.com Subject: Re: [TF-A] Proposal for Measured Boot Implementation

Hello Stuart, Alexei,

Chiming-in here on Ampere's behalf...

We analysed this proposal internally. And we see a number issues with this, some of which was already raised by Raghu in the previous threads.

Here is a summary of the main issues that we see.

* Only supporting mbedtls, and this is fixed config at compile time. * We propose that there should be a variable for the algorithm to be used, which can be setup at initialization time. * This solution relies on taking the hash directly from the digest as the measurement, instead of the computed hash. This is not safe, especially considering measured boot may use a different hash bank, so digest hash may not be correct/valid. * Only measuring the BL2 image, per the ARM SBSG we must be measuring and logging *all* images/boot phases * BL31 * BL32 (all secure partitions) * BL33 (UEFI or any other non-secure boot loader) * Once we ERET into BL33, the measure boot flow continues and is owned by that boot loader * Only see support for PCR0, any/all unsigned config data must be logged to PCR1. * Passing PCRs to non-secure software before logging is not compliant with TCG Static-Root-of-Trust Measurement (SRTM) requirements * It was discussed before in separate conversations… especially in systems where you are talked about two different signing domains where BL33 is a different trust/signing domain. * BL33 should only do hash-log-extend… there is no need for BL33 to be aware of the current PCR value (beyond what is provided in the boot event log). * Based on comments on the mail thread, there seem to be bad assumptions/expectations around TPM accessibility from non-secure world. * Expecting SPI/I2C TPMs to be directly accessed from non-secure world instead of abstracting hardware details via the TCG CRB interface (which has been already standardized as the defacto mechanism for ARM on past mobile, client, and server solutions). * CRB will "just work" for Aptio/EDK2/Linux/Windows/Hyper-V/VMWare * NOTE: This goes back to what is a “productizable” TPM solution. We want it to be turn-key solution for customers without having to support/develop proprietary drivers.

-Vivek/Harb