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

[Mikko Rapeli <mikko.rapeli@xxxxxxxxxx>]

On Tue, Apr 09, 2024 at 11:37:39AM +0300, Mikko Rapeli wrote:
> 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.

Turns out it was as simple building TPM drivers into the kernel.
Changing kernel config from

CONFIG_TCG_TIS_CORE=m
CONFIG_TCG_TIS=m

to

CONFIG_TCG_TIS_CORE=y
CONFIG_TCG_TIS=y

fixes the TPM2 device detection issues whole boot succeeds now with
dm-verity /usr and systemd-repart generated TPM2 protected rootfs.
With the tee-supplicant and kernel side support for RPMB this is now
ok since tee-supplicant isn't needed for optee RPMB reads and writes to
work, which needed tee driver reloads as workarounds.

If TPM2 drivers were not built into the kernel, where should they be
loaded in tpm2.target?

Cheers,

-Mikko