Hi Javier,

As discussed during the TF-A call, here are some suggestions/feedback that can be incorporated when time permits based on priorities, schedule, resources etc:

Would be good if the test infrastructure(the TPM TA) can compile in AARCH64. I thought I heard on the tf-a call that there already is a Microsoft FW TPM port for aarch64 already. Please let me know if I misunderstood.
Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s.
Provide platform hooks in tpm_record_measurement function for a platform to actually extend those measurements to a physical TPM right when they are measured. This is a requirement from a security perspective to not wait until the tpm TA is loaded to be able to extend the measurements into a tpm. I understand this can be done in the platform hook that calls tpm_record_measurement but it is convenient place to put tpm related platform hooks.
On platforms that use FCONF, the FW_CONFIG and TB_FW_CONFIG should also be measured since they are images being loaded as well. See arm_bl1_setup.c where these images are loaded but not measured(unless I’m missing something).

Thanks

Raghu

From: TF-A <tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Javier Almansa Sobrino via TF-A
Sent: Friday, October 9, 2020 10:51 AM
To: tf-a@lists.trustedfirmware.org
Subject: [TF-A] Questions raised about Measured Boot + fTPM test case

Hello all,

Following up the question raised yesterday during the TF-A Tech Forum with regards to any modification needed on the Linux Kernel to run the test case that I was presenting (Measured Boot + fTPM service), I double checked today and I ran some tests on system and I can confirm that the test case works with the mainline Linux Kernel, with no modification other than enabling the driver on the DTB.

The modules involved on the interaction with the fTPM (for this particular example) are:

* optee.ko: Allows communication between the REE (unsecure world), the Trusted OS (secure world) and the tee-supplicant (unsecure world).

* tpm_ftpm_tee.ko: Module to communicate with a firmware TPM through a char device. This also includes the reference implementation used on the test case.

In order to use the fTPM service, the test case makes use of IBM's TPM 2.0 TSS, a user space TSS for TPM 2.0 that uses services provided by the fTPM.

I would also like to highlight the following points:

A) The test case is only meant to test the ability of the Measured Boot Driver and a TPM 2.0 compliant device to interact with each other. As such, we are not providing an fTPM meant to be used on a production environment. Instead, we are using an existing reference implementation to which we added support for Measured Boot to fulfil our needs for the test and use it as a functional example. The implementation details on how to interact with a particular TPM device (either firmware or discrete) can differ from the ones used on the test case as those details can be platform dependent. For example, we use an OPTEE TA fTPM on this example, but other platforms might use a discrete TPM or an fTPM running on a different Trusted OS.

B) As stated on the presentation, we are undergoing internal review of the contributions done for the fTPM service to make it compatible with Measured Boot. Once the review is completed and the changes merged into the TPM repo mainline, we will update the TF-A documentation with instructions on how to download and build all the components to run the tests manually.

Please, let me know in case you have any more questions.

Best regards,

Javier