Re: Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)

[Mikko Rapeli <mikko.rapeli@xxxxxxxxxx>]

Hi,

On Mon, Feb 19, 2024 at 11:53:14AM +0100, Lennart Poettering wrote:
> For your usecase the new tpm2.target available in git main is what you
> really should focus on: all TPM using services should order themselves
> after that. All stuff needed to make a TPM device appear should be
> placed before that.
>
> The systemd-tpm2-generator that now exists in git main analyzes the
> uefi/acpi firmware situation and automatically adds a dev-tpm0.device
> dependency on tpm2.target if it comes to the conclusion that such a
> device will show up. This generator is not going to cover your
> specific case, but I think it would be a good blueprint for you:
> i.e. write a generator that checks if /dev/teepriv* exists. If not,
> just exit. If yes, generate the required deps to pull in
> tee-supplicatnt@.service, and add the dev-tpmrm0.device dep just like
> systemd-tpm2-generator does.

Thanks, I've ported the few remaining tpm2.target patches to systemd 255.4 which we use
from yocto poky. Patches roughly like here but needed some local changes which I'm
currently trying to test:
https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/merge_requests/82/diffs?commit_id=245086abcd96c24084a741037acc498523e5775b

I've also added kernel and optee changes which enable RPMB
usage without tee-supplicant userspace daemon but those need more
testing on boards with fTPM and RPMB support.

https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/merge_requests/82/diffs?commit_id=1a87039f42ad7a6178f47db8558874d98f19b2b2
https://gitlab.com/mikko.rapeli/meta-ts/-/commit/4d1b8d3885eb5a120d33796462145e9608f2ecfe

But currently I face a different problem which came from a yocto update/rebase.
There were a few fTPM related kernel regressions after update from 6.5.y to 6.6.y
( https://bugzilla.kernel.org/show_bug.cgi?id=218587 and
https://bugzilla.kernel.org/show_bug.cgi?id=218542 to be exact)
but systemd 254 update to 255.4 seems to also cause isses.

On 255.4 UEFI secure boot, uki loading and mounting dm-verity protected /usr work,
and also tpm2 target and creating a writable rootfs / with TPM2 encryption using
systemd-repart, but then cryptsetup unlocking seems to fail. What could I be missing?

Apr 09 07:57:56 trs-qemuarm64 systemd[1]: Reached target Trusted Platform Module.
sh-5.2# systemctl status systemd-repart.service -l --no-pager
* systemd-repart.service - Repartition Root Disk
     Loaded: loaded (/usr/lib/systemd/system/systemd-repart.service; static)
    Drop-In: /usr/lib/systemd/system/systemd-repart.service.d
             `-override.conf
     Active: active (exited) since Tue 2024-04-09 07:23:33 UTC; 1min 58s ago
       Docs: man:systemd-repart.service(8)
    Process: 209 ExecStart=/bin/sh -c /usr/bin/test -c /dev/tpmrm0 && /usr/bin/systemd-repart --dry-run=no --definitions=/usr/lib/repart.d/ || /usr/bin/systemd-repart --dry-run=no --definitions=/usr/lib/repart.d_notpm/ (code=exited, status=0/SUCCESS)
   Main PID: 209 (code=exited, status=0/SUCCESS)
        CPU: 6.777s

Apr 09 07:23:29 trs-qemuarm64 sh[220]: [83B blob data]
Apr 09 07:23:29 trs-qemuarm64 sh[211]: /dev/mapper/luks-repart-1ec7705a23c053fd successfully formatted as ext4 (label "root-arm64", uuid 54453b71-30e9-4b29-a593-e4298b2c0770)
Apr 09 07:23:29 trs-qemuarm64 sh[211]: Successfully formatted future partition 3.
Apr 09 07:23:29 trs-qemuarm64 sh[211]: Populating ext4 filesystem.
Apr 09 07:23:32 trs-qemuarm64 sh[211]: Successfully populated ext4 filesystem.
Apr 09 07:23:33 trs-qemuarm64 sh[211]: Adding new partition 3 to partition table.
Apr 09 07:23:33 trs-qemuarm64 sh[211]: Writing new partition table.
Apr 09 07:23:33 trs-qemuarm64 sh[211]: Telling kernel to reread partition table.
Apr 09 07:23:33 trs-qemuarm64 sh[211]: All done.
Apr 09 07:23:33 trs-qemuarm64 systemd[1]: Finished Repartition Root Disk.
sh-5.2# systemctl status systemd-cryptsetup@root.service -l --no-pager
x systemd-cryptsetup@root.service - Cryptography Setup for root
     Loaded: loaded (/run/systemd/generator.late/systemd-cryptsetup@root.service; generated)
    Drop-In: /usr/lib/systemd/system/systemd-cryptsetup@.service.d
             `-override.conf
     Active: failed (Result: exit-code) since Tue 2024-04-09 07:23:35 UTC; 2min 28s ago
       Docs: man:crypttab(5)
             man:systemd-cryptsetup-generator(8)
             man:systemd-cryptsetup@.service(8)
    Process: 234 ExecStart=/usr/bin/systemd-cryptsetup attach root /dev/gpt-auto-root-luks   (code=exited, status=1/FAILURE)
   Main PID: 234 (code=exited, status=1/FAILURE)
        CPU: 810ms

Apr 09 07:23:34 trs-qemuarm64 systemd[1]: Starting Cryptography Setup for root...
Apr 09 07:23:35 trs-qemuarm64 systemd-cryptsetup[234]: No passphrase or recovery key registered.
Apr 09 07:23:35 trs-qemuarm64 systemd[1]: systemd-cryptsetup@root.service: Main process exited, code=exited, status=1/FAILURE
Apr 09 07:23:35 trs-qemuarm64 systemd[1]: systemd-cryptsetup@root.service: Failed with result 'exit-code'.
Apr 09 07:23:35 trs-qemuarm64 systemd[1]: Failed to start Cryptography Setup for root.

Full boot failure log with blkid etc debug commands on qemu arm64 machine with swtpm
is here: https://pastebin.com/raw/6xy5x5NP

So the rootfs is tied to TPM2 device and there should not be any
passphrase or recovery key. I'm trying to use partition autodiscovery
everywhere.

I tried to cherry-pick systemd main branch fixes like to 255.4:
https://github.com/systemd/systemd/commit/0d5f59a248b50d7a3018ebfcdb13a2ddf0ff6e54
https://github.com/systemd/systemd/commit/ce18410a54424dd247805a93ebfc515d875f999e
but those didn't solve this.

This step was working on systemd 254 branch before, so maybe I missed something
in config changes or there is a difference between systemd 254 and 255.

Thanks for any pointers. Cheers,

-Mikko