Hi Benoit,
On 3/3/23 17:30, Benoit Sansoni via TF-A wrote:
Hello,
I am working on a board based on NXP LS1043 processor (arm64) with TPM2 on SPI interface. I have the following boot sequence : TF-A + UBOOT + YOCTO. I have a look on the code where the TF-A MEASURE_BOOT was implemented for the fvp arm platform using OPTEE fTPM.
As far as I understood, the event log is implemented based on the TCG2 EFI PROTOCOL from commit :
commit 3ee148d6439b69d326f8e6d2a4ce822604e0e64c Merge: 43f7d8879 4a135bc33 Author: joanna.farley joanna.farley@arm.com Date: Wed Jul 22 16:35:11 2020 +0000
Indeed.
Nevertheless, I am surprised because I did not find any TPM2 driver in the current TF-A code.
That's right, there is no discrete TPM2 driver in the TF-A code base right now, this is not supported. Measurements only get stored into a TCG event log held in secure memory.
To test the measured boot framework in TF-A, we put together a proof of concept, whereby the event log gets passed to a firmware TPM (fTPM) service implemented on top of OP-TEE, which replays the measurements from the data inside the event log.
The following document provides useful information about this proof of concept:
https://trustedfirmware-a.readthedocs.io/en/latest/design_documents/measured...
More recently, we've extended the measured boot framework in TF-A to securely store measurements into the Runtime Security Subsystem (RSS) [1], which is an independent core providing fundamental security guarantees and runtime services on some Arm solutions platforms.
The reason I am mentioning RSS here is because, from a measured boot angle, it is closer to a discrete TPM chip, in that measurements get pushed to the RSS as soon as they are made, instead of being deferred to a S-EL0 fTPM trusted application. So in that sense it is closer to your requirements. I recommend having a look at section 9.5.3. "RSS based Measured Boot" in [1] for more details.
As part of this work, we re-designed parts of the measured boot framework to accommodate the RSS requirements. Hopefully, one should be able to leverage the same interfaces as used by RSS for a TPM2 driver.
The framework is conceptually divided in 2 pieces, a frontend and a backend. The frontend is meant to stay the same but it can be interfaced with different backends. We support 2 backends right now: TCG event log and RSS. Adding support for dTPM would mean either extending the existing TCG event log or adding it as a third backend if we want to retain the ability to only use the TCG event log without TPM (which I think is desirable).
I would like to know :
- How to port what was done for the fvp platform to my platform ?
You will need to implement all platform interfaces related to measured boot. For a list of them, please search for all function names containing "plat_mboot" in the porting guide [2]. For reference, here is the full list:
plat_mboot_measure_image() plat_mboot_measure_critical_data()
bl1_plat_mboot_init() bl1_plat_mboot_finish()
bl2_plat_mboot_init() bl2_plat_mboot_finish()
- What is code hashed in the TFA to create the event log ?
The list of images to measure (firmware binaries, firmware configuration files, critical data) is platform-specific and thus needs to be described by the platform layer. Here is what it looks like for Arm FVP platform:
Measurements made by BL1:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo...
Measurements made by BL2:
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/bo...
- Why are there no TPM2 routine in the TF-A to expend PCR ?
As mentioned above, measurements are not stored into a TPM2 chip, they are only stored in the event log. This is a gap in the TPM-based measured boot solution in TF-A, which we'd be interested to fill. We would be very happy to receive such a contribution to TF-A project.
Thanks in advance for your help Benoit
Best regards, Sandrine
[1] https://trustedfirmware-a.readthedocs.io/en/latest/design_documents/rss.html
[2] https://trustedfirmware-a.readthedocs.io/en/latest/getting_started/porting-g...