fTPM Early TA on boot problems with initramfs

[mlazarou-git]

Hello, I am trying Microsoft's fTPM TA in OPTEE and Firmware TPM Driver as part of my thesis implementation for remote attestation mechanism in embedded devices. The main idea is to extend IMA measurements digest in PCRs and with the help of the tpm2 tools demostrate an Remote Attestation procedure. Currently, i am using STM32MP157C-DK2 board, initially flashed with its starter package (TF-A, OPTEE, U-Boot, OpenSTLinux), then:

1. Changed OpenSTLinux filesystem to debian for arm
2. Modified the Linux kernel with IMA/EVM, TPM_FTPM_TEE modules
3. Modified the device tree to support fTPM as i found in add dts documentation for fTPM driver and in meta-ledge repository.
4. Compiled OPTEE with Microsoft's fTPM as Early TA
5. Created a tee-supplicant service and add it to initramfs with dracut as described here: Securing a device with Trusted Substrate

I tried manually (before the initramfs modification) to enable tee-supplicant and modprobe fTPM kernel driver and as expected /dev/tpmX devices appeared and tpm-tools were working. My next assumption is to have a functional fTPM early on boot for IMA module to take advantage or even for a measured boot procedure leveraging PCRs and Event log.

My current implementation is fTPM as Early TA and tee-supplicant starts by the initramfs like how it is mentioned in #5347:

On the platform I am currently working on (RockPi4B):

• the fTPM TA is an early TA so that it doesn't need to be loaded from the root filesystem (it is readily available after OP-TEE initialization)
• OP-TEE is configured to use RPMB only (CFG_REE_FS=n CFG_RPMB_FS=y) and tee-supplicant is started by the initramfs. This way the fTPM TA can access secure storage before the root filesystem is mounted.

The fTPM now seems trying to start as soon as the tee-supplicant is ready by initramfs

Welcome to Debian GNU/Linux 11 (bullseye) dracut- (Initramfs)! [ OK ] Started tee supplicant. [ OK ] Finished dracut initqueue hook. [ OK ] Found device /dev/disk/by-…9-e0cb-c544-9823-8829036287db. D/TA: _platNVEnable:365 _plat__NVEnable() D/TA: _platNVEnable:377 s_NV is at 0x40050850 and is size 0x5000 D/TA: _platNvInitFromStorage:113 _plat__NvInitFromStorage() D/TA: _platNvInitFromStorage:141 fTPM:Opening block 0 of 5 E/TC:? 1 tee_rpmb_verify_key_sync_counter:1013 Verify key returning 0xffff0008 D/TA: _plat__NvInitFromStorage:159 fTPM: block 0 not found, creating [ OK ] Reached target Initrd Root Device. [ OK ] Reached target Remote File Systems (Pre). [ OK ] Reached target Remote Encrypted Volumes. [ OK ] Reached target Remote File Systems. Starting dracut pre-mount hook... [ OK ] Finished dracut pre-mount hook. Starting File System Check…e0cb-c544-9823-8829036287db... [ OK ] Finished File System Check…9-e0cb-c544-9823-8829036287db. Mounting /sysroot... [ 18.616075] EXT4-fs (mmcblk0p10): mounted filesystem with ordered data mode. Opts: i_version. Quota mode: disab. [ OK ] Mounted /sysroot. I/TA: Created fTPM storage object, i: 0x0, s: 0x1000, id: 0x54504d00, h:0x29e30 D/TA: _plat__NvInitFromStorage:141 fTPM:Opening block 1 of 5 [ OK ] Reached target Initrd Root File System. Starting Reload Configuration from the Real Root... D/TA: _platNvInitFromStorage:159 fTPM: block 1 not found, creating I/TA: Created fTPM storage object, i: 0x1, s: 0x1000, id: 0x54504d01, h:0x29b28 D/TA: _plat__NvInitFromStorage:141 fTPM:Opening block 2 of 5 D/TA: _platNvInitFromStorage:159 fTPM: block 2 not found, creating I/TA: Created fTPM storage object, i: 0x2, s: 0x1000, id: 0x54504d02, h:0x29868 D/TA: _plat__NvInitFromStorage:141 fTPM:Opening block 3 of 5 D/TA: _plat__NvInitFromStorage:159 fTPM: block 3 not found, creating [ OK ] Finished Reload Configuration from the Real Root. [ OK ] Reached target Initrd File Systems. [ OK ] Reached target Initrd Default Target. Starting dracut pre-pivot and cleanup hook... [ OK ] Finished dracut pre-pivot and cleanup hook. Starting Cleaning Up and Shutting Down Daemons... [ OK ] Finished Cleaning Up and Shutting Down Daemons. [ OK ] Stopped target Remote Encrypted Volumes. [ OK ] Stopped target Timers. [ OK ] Stopped dracut pre-pivot and cleanup hook. [ OK ] Stopped target Initrd Default Target. [ OK ] Stopped target Initrd Root Device. [ OK ] Stopped target Remote File Systems. [ OK ] Stopped target Remote File Systems (Pre). [ OK ] Stopped dracut pre-mount hook. [ OK ] Stopped dracut initqueue hook. Stopping tee supplicant... [ OK ] Stopped tee supplicant.

Problem 1: fTPM seems to start making some secure storage object and then stops in 3 of 5 blocks, tee-supplicant stops and the boot continues.

Problem 2: When boot is done fTPM kernel module seems to be enabled and used but there is no /dev/tpmX device so tpm-tools can't be used.

debian@arm:~$ lsmod Module Size Used by tpm_ftpm_tee 16384 1

Problem 3: After tee-supplicant has been started and stopped by initramfs, tee-supplicant service (or daemon) can't be started again throwing errors.

Jan 13 14:41:23 arm systemd[1]: tee-supplicant.service: Start request repeated too quickly. Jan 13 14:41:23 arm systemd[1]: tee-supplicant.service: Failed with result 'exit-code'. Jan 13 14:41:23 arm systemd[1]: Failed to start tee supplicant.

Also some more things that maybe be useful:

Since the dracut modification with tee-supplicant.service some issues that i haven't solve yet happened.

1. Ordering cycles in the start of initramfs boot

Welcome to Debian GNU/Linux 11 (bullseye) dracut- (Initramfs)!

[ 6.401237] systemd[1]: No hostname configured. [ 6.404447] systemd[1]: Set hostname to . [ 6.409775] systemd[1]: Initializing machine ID from random generator. [ 7.407611] systemd[1]: sysinit.target: Found ordering cycle on cryptsetup.target/start [ 7.414465] systemd[1]: sysinit.target: Found dependency on tee-supplicant.service/start [ 7.422491] systemd[1]: sysinit.target: Found dependency on sysinit.target/start [ 7.429696] systemd[1]: sysinit.target: Job cryptsetup.target/start deleted to break ordering cycle starting

2. Reboot of the system stucks and waiting for process systemd-udevd. I already added DefaultDependencies=no in tee-supplicant.service as some articles suggested but nothing changed.

[ 685.177719] watchdog: watchdog0: watchdog did not stop! [ 686.006329] systemd-shutdown[1]: Syncing filesystems and block devices. [ 686.059949] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 686.099275] systemd-journald[460]: Received SIGTERM from PID 1 (systemd-shutdow). [ 696.128916] systemd-shutdown[1]: Waiting for process: systemd-udevd [ 776.140944] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 776.167279] systemd-shutdown[1]: Sending SIGKILL to PID 318 (systemd-udevd).

Any feedback for the problems, the git issue or my implementation approach would be really appreciated. Thank you in advance.

[etienne-lms]

Hello @mlazarou-git, STM32MP15XX-DK2 boards do not integrate an eMMC device hence no RPMB partition. With this config, the RPMB is likely emulated in userland tee-supplicant RAM (RPMB_EMU=y or BR2_PACKAGE_OPTEE_CLIENT_EXT_RPMB_EMU=y). With this config, RPMB is not persistent and you need to set CFG_RPMB_WRITE_KEY=y and use any key you want.

To use fTPM measurements only from linux (no measument before tee-supplicant is started), we you should use the REE_FS (CFG_REE_FS=y CFG_RPMB_FS=n) but without effective rollback protection. For effective roolback protection thanks to RPMB (including measurements before Linux boots), you need an stm32mp15XX-EV1 board, they integrate an eMMC device when you can set CFG_RPMB_FS=y in optee_os and RPMB_EMU=n in optee_client.

When enabling RPMB, tee-supplicant needs specific privileges (blk group, etc...) worked around when run as root, but that part higly depends on the distro your using.

I'll test again fTPM with the prepared 3.20.0-rc1 and give you some feedback.

(edited)

[github-actions[bot]]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.

[mlazarou-git]

@etienne-lms thank you for your useful information, i tested the firmware TPM with the Evaluation board and it seems to work as expected. I will continue my implementation and check if the IMA measurements can be extended into PCRs early on boot to later perform remote attestation requests.