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 tf-a-bounces@lists.trustedfirmware.org on behalf of Javier Almansa Sobrino via TF-A tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org *Sent:* 26 October 2020 10:25 *To:* raghu.ncstate@icloud.com raghu.ncstate@icloud.com raghu.ncstate@icloud.com *Cc:* tf-a@lists.trustedfirmware.org 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----- *From*: raghu.ncstate@icloud.com *To*: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino@arm.com <'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino@arm.com%3e>> *Cc*: 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:
- 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 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
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 mailto: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 mailto:tf-a-bounces@lists.trustedfirmware.org tf-a-bounces@lists.trustedfirmware.org on behalf of Javier Almansa Sobrino via TF-A mailto:tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Sent: 26 October 2020 10:25 To: raghu.ncstate@icloud.com mailto:raghu.ncstate@icloud.com mailto:raghu.ncstate@icloud.com raghu.ncstate@icloud.com Cc: tf-a@lists.trustedfirmware.org mailto:tf-a@lists.trustedfirmware.org mailto: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-----
From: raghu.ncstate@icloud.com mailto:raghu.ncstate@icloud.com
To: 'Javier Almansa Sobrino' <Javier.AlmansaSobrino@arm.com mailto:'Javier%20Almansa%20Sobrino'%20%3cJavier.AlmansaSobrino@arm.com%3e >
Cc: tf-a@lists.trustedfirmware.org mailto: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 mailto:tf-a-bounces@lists.trustedfirmware.org 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 mailto: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
On 10/29/20 4:23 PM, raghu.ncstate@icloud.com wrote:
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.
Agree with Raghu that it is preferred to have the entities doing the measurement extend them into the TPM. The greater the window of time between measurement and storing in the TPM the more risk.
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.
If it's feasible for the bootrom to make measurements into the TPM that would be ideal. Since this is in ROM which is fixed in the SoC prior to tape out there could be challenges depending on how the TPM is integrated into the system-- things like which SPI chip select to assert, etc. It means needing a SPI/I2C controller driver, minimal TPM driver, etc.
Thanks, Stuart
tf-a@lists.trustedfirmware.org
-
raghu.ncstate＠icloud.com -
Ruchika Gupta -
Stuart Yoder