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:
1. 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. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. 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. 4. 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
Hi Raghu,
Thank you very much for your comments and for your feedback.
With regards to the (f)TPM service and as discussed during the last TF-A Tech Forum call, we will discuss internally the need of a new implementation, probably after the next TF-A release, and we will schedule the work (in case we decide to go ahead with it) for the upcoming months. We will announce any decision we make through the mailing list and/or on future TF-A Tech Forum calls .
Regarding to changes to TF-A to include extra functionality/APIs/hooks, I guess my colleague Alexei can provide further details about the next features planned for Measured Boot, if any.
To finish, I would just like to clarify one of the questions raised on your email:
[1] 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.
* Microsoft has a reference implementation of the TPM 2.0 specification. That implementation is in the form of an architecture agnostic library that implements the specification. Along with the library, there are a couple of example applications for different platforms built around the former, one of them being the fTPM we used for testing. That application was written for AARCH32 and seemed to be outdated (I don't know if it was abandoned, actually), so we updated it and added support for Measured Boot to it.
Best regards, Javier
-----Original Message----- From: raghu.ncstate@icloud.commailto:raghu.ncstate@icloud.com To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino@arm.commailto:'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino@arm.com%3e> Cc: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org Subject: RE: [TF-A] Questions raised about Measured Boot + fTPM test case Date: Sun, 25 Oct 2020 14:31:10 -0700
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:
1. 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. 2. Would be good if the TPM TA works on FF-A as opposed to proprietary OPTEE API’s. 3. 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. 4. 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
tf-a@lists.trustedfirmware.org
-
Javier Almansa Sobrino -
raghu.ncstate＠icloud.com