[systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)

Fri Apr 12 14:03:18 UTC 2024

Shouldn't the kernel automatically load the necessary modues when
devices are detected... given proper udev rules and module
availability in the initrd filesystem? I guess it depends on how you
build your initrd system for including them.

On Wed, Apr 10, 2024 at 10:24 AM Mikko Rapeli <mikko.rapeli at linaro.org> wrote:
>
> 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 at .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 at root.service -l --no-pager
> > x systemd-cryptsetup at root.service - Cryptography Setup for root
> >      Loaded: loaded (/run/systemd/generator.late/systemd-cryptsetup at root.service; generated)
> >     Drop-In: /usr/lib/systemd/system/systemd-cryptsetup at .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 at .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 at root.service: Main process exited, code=exited, status=1/FAILURE
> > Apr 09 07:23:35 trs-qemuarm64 systemd[1]: systemd-cryptsetup at 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
>