Thanks for the link Ruchika.

 

>> Case 1.  Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow.

In my view, this is where ARM platforms should be heading to rather than waiting for the TPM app to load, parse event log from secure memory and then extend measurements into the TPM. The CRTM starts getting too large at this point and a single exploit in any code executing after BL1 would make measured boot less reliable. Note that this model of extending measurements later creates dependency on having secure boot for BL2, BL31 etc. Ideally measured boot and secure boot are independent security features providing different properties.

 

>> Case 2.  If BL1 and BL2 don't have the TPM driver as mentioned in  Case 1 above, who would be responsible for extending the measurements for secure world entities.

See page 21 of https://developer.arm.com/documentation/den0086/latest.  It should answer both questions. SBSG says that the TPM driver can be a part of Secure EL0 and since the S-EL0 partition/driver is not up yet during early boot(bl1, bl2, bl31, bl32 etc), it is permissible for these stages to record measurements in secure memory and have it replayed to the TPM once secure EL0 is up. The TPM driver/S-EL0 app should own the TPM and its physical bus and should provide an SMC interface for UEFI to use to continue extending measurements. This is my understanding of what is done today by TF-A.

 

Stuart, SBSG says “It is acceptable for the first mutable firmware component to measure itself because it has been verified by the immutable bootloader and is then trusted.”. I would suggest that you strongly recommend extending first mutable code measurements in immutable code to the TPM, in SBSG. This may have been acceptable a few years ago but in all likelihood will not be acceptable in the near future.

 

Thanks

Raghu

 

From: Ruchika Gupta <ruchika.gupta@linaro.org>
Sent: Monday, October 26, 2020 10:06 PM
To: Stuart Yoder <stuart.yoder@arm.com>
Cc: Alexei Fedorov <Alexei.Fedorov@arm.com>; raghu.ncstate@icloud.com; Javier Almansa Sobrino <Javier.AlmansaSobrino@arm.com>; tf-a@lists.trustedfirmware.org
Subject: Re: [TF-A] Questions raised about Measured Boot + fTPM test case

 

Hi,

 

For [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.

You can check the implementation at 

 https://github.com/microsoft/MSRSec

This compiles for aarch64.

 

I had a few queries for chips having physical TPM. 

 

Case 1.  Should all entities doing the measurement (BL1, BL2) have the TPM driver to extend the measurements as they are done. This would be the most secure flow.

Case 2.  If BL1 and BL2 don't have the TPM driver as mentioned in  Case 1 above, who would be responsible for extending the measurements for secure world entities.

-- Should there be a TPM driver in Secure EL0/EL1 which does this ?

-- Event log is also passed to the BL33. In case there is no TPM driver at all in the secure world - is it expected that BL33 should extend the measurements in PCR ?

 

Regards,

Ruchika

 

On Mon, 26 Oct 2020 at 21:03, Stuart Yoder via TF-A <tf-a@lists.trustedfirmware.org> wrote:

Regarding measuring TB_FW_CONFIG--

BL1 could measure the unmodified TB_FW_CONFIG image as it was loaded from flash.  It could then update TB_FW_CONFIG with that measurement which reflects the image as it was on flash.  This could allow detection of tampering with flash.  I would recommend doing this, as TB_FW_CONFIG is critical data.

BL2 could make a measurement of the TB_FW_CONFIG image as it was passed to it in memory.

Thanks,
Stuart

On 10/26/20 6:16 AM, Alexei Fedorov wrote:

Hi Javer,

 

Please see my comments below.

 

[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.

    

These hooks can be implemented in the next phase #2 of Measured Boot implementation.

 

[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).

 

FW_CONFIG and TB_FW_CONFIG images are loaded by BL1 but not BL2.

BL1 calculates BL2 hash and passes the measurement to BL2 in TB_FW_CONFIG.

It can also pass FW_CONFIG hash in the same DTB, but it is not clear how own TB_FW_CONFIG  hash can be passed in itself.

 

Stuart, do you have opinion on that?

 

Regards.

Alexei


From: TF-A <tf-a-bounces@lists.trustedfirmware.org> on behalf of Javier Almansa Sobrino via TF-A <tf-a@lists.trustedfirmware.org>
Sent: 26 October 2020 10:25
To: raghu.ncstate@icloud.com <raghu.ncstate@icloud.com>
Cc: tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.org>
Subject: Re: [TF-A] Questions raised about Measured Boot + fTPM test case

 

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-----

To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino@arm.com>

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 mailing list
TF-A@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a