Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Tue, Apr 16, 2024 at 04:03:25PM +0200, Lennart Poettering wrote: > On Di, 16.04.24 15:02, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Hi, > > > > On Mon, Apr 15, 2024 at 05:41:00PM +0200, Lennart Poettering wrote: > > > Would be good to have that with systemd.log_target=debug, to see if > > > tpm2.target even gets enqueued. > > > > Here is the verbose log: > > > > https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_failure.txt > > So that shows that tpm2.target is only enqueued once the /dev/tpmrm0 > device actually shows up. But that makes it useless. The idea is that > the target is already enqueued when during very early setup in > systemd-tpm2-generator we come to the conclusion that "yes, a tpm2 > device has not been found and set up by Linux yet, but the firmware > indicates there is one, hence let's schedule a job for it, that > everything can sync on". But this determination never happened > here, tpm2.target was never enqueued, hence never acted as a > synchronization milestone. > > (As a temporary hack you can *force* systemd-tpm2-generator to assume > that a TPM device will show up via systemd.tpm2_wait=1 on the kernel > cmdline, and thus enqueue tpm2.target. But that's only suitable as > local hack: we should be able to determine all this automatically > based on firmware properties, see below.) > > > System is qemu arm64 with UEFI / ARM System Ready compatible firmware, > > secure boot and TPM2 device via swtpm. > > So this firmware implements UEFI and ACPI? As indication whether the > firmware supports TPM2, we check for the existance of the > /sys/firmware/acpi/tables/TPM2 ACPI table. Does that exist for you? > > See src/share/efi-api.c, function efi_has_tpm2(). > > Do you have /sys/kernel/security/tpm0/binary_bios_measurements? > > > systemd-tpm2-setup-early.service: ConditionSecurity=measured-uki > > failed. > > So this suggests you haven't booted the system with a UKI or that your > firmware doesn#t actually do TPM. > > Or in other words: ConditionSecurity=measured-uki will only hold if > the aforementioned ACPI table exists *and* the StubPcrKernelImage EFI > variable is found to be set. At least in this case with qemu and swtpm, the TPM device support is available via devicetree and thus with check for /proc/device-tree/tpm-event-log via https://github.com/systemd/systemd/pull/32314 the TPM2 devices gets correctly detected and once kernel modules get loaded ConditionSecurity=measured-uki passes. Boot log here: https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_devicetree_fix.txt Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Tue, Apr 16, 2024 at 04:03:25PM +0200, Lennart Poettering wrote: > On Di, 16.04.24 15:02, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Hi, > > > > On Mon, Apr 15, 2024 at 05:41:00PM +0200, Lennart Poettering wrote: > > > Would be good to have that with systemd.log_target=debug, to see if > > > tpm2.target even gets enqueued. > > > > Here is the verbose log: > > > > https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_failure.txt > > So that shows that tpm2.target is only enqueued once the /dev/tpmrm0 > device actually shows up. But that makes it useless. The idea is that > the target is already enqueued when during very early setup in > systemd-tpm2-generator we come to the conclusion that "yes, a tpm2 > device has not been found and set up by Linux yet, but the firmware > indicates there is one, hence let's schedule a job for it, that > everything can sync on". But this determination never happened > here, tpm2.target was never enqueued, hence never acted as a > synchronization milestone. > > (As a temporary hack you can *force* systemd-tpm2-generator to assume > that a TPM device will show up via systemd.tpm2_wait=1 on the kernel > cmdline, and thus enqueue tpm2.target. But that's only suitable as > local hack: we should be able to determine all this automatically > based on firmware properties, see below.) Thanks, this is useful. I will try this out. > > System is qemu arm64 with UEFI / ARM System Ready compatible firmware, > > secure boot and TPM2 device via swtpm. > > So this firmware implements UEFI and ACPI? As indication whether the > firmware supports TPM2, we check for the existance of the > /sys/firmware/acpi/tables/TPM2 ACPI table. Does that exist for you? On qemu with swtpm, no this doesn't exist. > See src/share/efi-api.c, function efi_has_tpm2(). > > Do you have /sys/kernel/security/tpm0/binary_bios_measurements? But this does exist. > > systemd-tpm2-setup-early.service: ConditionSecurity=measured-uki > > failed. > > So this suggests you haven't booted the system with a UKI or that your > firmware doesn#t actually do TPM. It's the latter. In this, granted artificial, case firmware doesn't know about TPM implemented by swtpm but it is setup as a char devices to qemu. I guess I could amend this in this configuration to be ConditionSecurity=tpm2 which would enable TPM use even firmware support for it doesn't exist. This changed between 254 and 255 but I think I got the reasons now. What is a bit odd is that when kernel modules are built into the kernel, then all of these work and ConditionSecurity=measured-uki is true. Also in this case /sys/firmware/acpi/tables/TPM2 does not exist but /sys/kernel/security/tpm0/binary_bios_measurements does. Full log here: https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_passing.txt Cheers, -Mikko > Or in other words: ConditionSecurity=measured-uki will only hold if > the aforementioned ACPI table exists *and* the StubPcrKernelImage EFI > variable is found to be set. > > Lennart
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Di, 16.04.24 15:02, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Hi, > > On Mon, Apr 15, 2024 at 05:41:00PM +0200, Lennart Poettering wrote: > > Would be good to have that with systemd.log_target=debug, to see if > > tpm2.target even gets enqueued. > > Here is the verbose log: > > https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_failure.txt So that shows that tpm2.target is only enqueued once the /dev/tpmrm0 device actually shows up. But that makes it useless. The idea is that the target is already enqueued when during very early setup in systemd-tpm2-generator we come to the conclusion that "yes, a tpm2 device has not been found and set up by Linux yet, but the firmware indicates there is one, hence let's schedule a job for it, that everything can sync on". But this determination never happened here, tpm2.target was never enqueued, hence never acted as a synchronization milestone. (As a temporary hack you can *force* systemd-tpm2-generator to assume that a TPM device will show up via systemd.tpm2_wait=1 on the kernel cmdline, and thus enqueue tpm2.target. But that's only suitable as local hack: we should be able to determine all this automatically based on firmware properties, see below.) > System is qemu arm64 with UEFI / ARM System Ready compatible firmware, > secure boot and TPM2 device via swtpm. So this firmware implements UEFI and ACPI? As indication whether the firmware supports TPM2, we check for the existance of the /sys/firmware/acpi/tables/TPM2 ACPI table. Does that exist for you? See src/share/efi-api.c, function efi_has_tpm2(). Do you have /sys/kernel/security/tpm0/binary_bios_measurements? > systemd-tpm2-setup-early.service: ConditionSecurity=measured-uki > failed. So this suggests you haven't booted the system with a UKI or that your firmware doesn#t actually do TPM. Or in other words: ConditionSecurity=measured-uki will only hold if the aforementioned ACPI table exists *and* the StubPcrKernelImage EFI variable is found to be set. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Mon, Apr 15, 2024 at 05:41:00PM +0200, Lennart Poettering wrote: > Would be good to have that with systemd.log_target=debug, to see if > tpm2.target even gets enqueued. Here is the verbose log: https://people.linaro.org/~mikko.rapeli/systemd_255_tpm2_target_qemu_swtpm_boot_encryption_failure.txt System is qemu arm64 with UEFI / ARM System Ready compatible firmware, secure boot and TPM2 device via swtpm. It boots a uki binary with kernel 6.6.20 and systemd based initramfs which creates a TPM2 backed encrypted rootfs. Kernel TPM drivers are modules and available in the initramfs for udev to load. .wic file system image for qemu contains empty space for the rootfs and dm-verity protected /usr partition which is auto-detected based on kernel command line. systemd is version 255 from stable branch commit 387a14a7b67b8b76adaed4175e14bb7e39b2f738 and following patches applied to try to fix these TPM and module loading issues: cryptsetup-tokens: fix argument order mismatch in function tpm2-setup: Add --graceful units: add a tpm2.target synchronization point and small generator that pulls in units: order repart after systemd-tpm2-setup-early.service Creating the new rootfs via systemd-repart.service succeeds like blkid debug command also shows. Mounting the newly created rootfs fails at systemd-cryptsetup@root.service step. For some reason it is trying to open the disk with password or pin, it should be using keys etc protected with the TPM2 device. ConditionSecurity=measured-uki seems to fail in multiple locations. tpm_tis support gets detected by udev and modules are loaded, which is visible in the emergency shell with lsmod. tpm2.target does run. systemd-tpm2-setup-early.service: ConditionPathExists=!/run/systemd/tpm2-srk-public-key.pem succeeded. but systemd-tpm2-setup-early.service: ConditionSecurity=measured-uki failed. AFAIK this used to be ConditionSecurity=tpm2 in systemd 254 where this step worked for me, but with more backported patches. uki binary is not run with --measure/systemd-measure since the uki binary is already protected with UEFI secure boot signatures and /usr is dm-verity protected with kernel command line inside uki binding the two. TPM2 device is only used to setup a device specific protected and writable root partition on first boot. So something with the tpm2 drivers-as-modules approach is still not working even with the tpm2.target patches. Same system with built in TPM drivers is able mount the newly created TPM backed rootfs, and after initramfs phase, boot to the dm-verity protected /usr partition works too. Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Mon, Apr 15, 2024 at 05:45:49PM +0200, Lennart Poettering wrote: > On Mo, 15.04.24 17:41, Lennart Poettering (lenn...@poettering.net) wrote: > > > > or the services needed for systemd-repart config with Encrypt=tpm2 > > > > Ah, repart is interesting. We are missing the tpm2.target dependency > > there. That's a bug. Will fix. > > → https://github.com/systemd/systemd/pull/32283 Thanks, testing with this too. systemd-repart run was not a problem with TPM drivers as modules, but the mount of the newly created TPM2 backed partition was failing. I'll capture the debug logs from that... Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Mo, 15.04.24 17:41, Lennart Poettering (lenn...@poettering.net) wrote: > > or the services needed for systemd-repart config with Encrypt=tpm2 > > Ah, repart is interesting. We are missing the tpm2.target dependency > there. That's a bug. Will fix. → https://github.com/systemd/systemd/pull/32283 Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Mo, 15.04.24 17:23, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Hi, > > On Mon, Apr 15, 2024 at 04:02:46PM +0200, Lennart Poettering wrote: > > On Mo, 15.04.24 10:38, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > > > Hi, > > > > > > On Fri, Apr 12, 2024 at 05:03:18PM +0300, Aleksandar Kostadinov wrote: > > > > 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. > > > > > > The modules do get loaded but too late in the initramfs stage and > > > something > > > in the tpm2.target and related service was failing and creating TPM2 > > > encrypted > > > rootfs fails. I could not figure out at which stage the driver needs to > > > be loaded, > > > e.g. > > > Before: modprobe@tpm_tis_core.service modprobe@tpm_tis.service > > > modprobe@tpm_ftpm_tee.service > > > > > > But I'm also trying to fix the root causes why TPM modules can't be built > > > into the > > > kernel so lucky that resolves these issues. Would be nice to know to > > > which stage > > > the TPM2 module loading would need to happen though. > > > > This should not require manual handling. The driver should be > > auto-loaded via udev and stuff, like any other driver. Or does the > > "tpm-ftpm_tee" thing carry no modalias info that autoloads it if some > > specific hw is around? > > With latest rebase/update from systemd 254 to 255 I'm not yet testing on fTPM > devices > but trying to get TPM2 backed rootfs genereted with qemu and swtpm which > required basic > tpm_tis_core and tpm_tis modules to be loaded. udev does load them but too > late > for tpm2.target mm? the only purpose of tpm2.target is to only show up once /dev/tpmrm0 actually has materialized. It comes with these two deps: After=dev-tpmrm0.device Wants=dev-tpmrm0.device This basically means that if tpm.target is enqueued into the boot, it will delay it forver basically — unless /dev/tpmrm0 shows up. Are you sure tpm2.target even gets enqueued for you though? That's normally the responsibility of systemd-tpm2-generator, whose job is to see if the firmware reported that it talked to a TPM2 device. And if it did, then it will assume the device will show up on Linux too if we just wait long enough for that, and for that it enqueus tpm2.target. I really have no idea about your platform, but it this is not an ACPI/UEFI device, then you have to enqueue tpm2.target some other way if you determine that "yes, the device has a tpm2 device, but no Linux hasn't found it yet. Probably means adding another generator (or if this reasonably generic, then we cal also add it to the upstream systemd-tpm2-generator, for example if this info is reasonably available from DT metadata or so). > or the services needed for systemd-repart config with Encrypt=tpm2 Ah, repart is interesting. We are missing the tpm2.target dependency there. That's a bug. Will fix. > to work. Changing TPM drivers to built-in fixed all these issues, and I'm now > able to > do this since I have the RPMB in kernel patches applied and tee-supplicant is > not needed > anymore. The issue with TPM drivers as modules was somewhere in the mount of > the > newly created TPM2 backed filesystem, possibly ConditionSecurity=measured-uki > failing. > > Full boot log in: https://pastebin.com/raw/6xy5x5NP Would be good to have that with systemd.log_target=debug, to see if tpm2.target even gets enqueued. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Mon, Apr 15, 2024 at 04:02:46PM +0200, Lennart Poettering wrote: > On Mo, 15.04.24 10:38, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Hi, > > > > On Fri, Apr 12, 2024 at 05:03:18PM +0300, Aleksandar Kostadinov wrote: > > > 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. > > > > The modules do get loaded but too late in the initramfs stage and something > > in the tpm2.target and related service was failing and creating TPM2 > > encrypted > > rootfs fails. I could not figure out at which stage the driver needs to be > > loaded, > > e.g. > > Before: modprobe@tpm_tis_core.service modprobe@tpm_tis.service > > modprobe@tpm_ftpm_tee.service > > > > But I'm also trying to fix the root causes why TPM modules can't be built > > into the > > kernel so lucky that resolves these issues. Would be nice to know to which > > stage > > the TPM2 module loading would need to happen though. > > This should not require manual handling. The driver should be > auto-loaded via udev and stuff, like any other driver. Or does the > "tpm-ftpm_tee" thing carry no modalias info that autoloads it if some > specific hw is around? With latest rebase/update from systemd 254 to 255 I'm not yet testing on fTPM devices but trying to get TPM2 backed rootfs genereted with qemu and swtpm which required basic tpm_tis_core and tpm_tis modules to be loaded. udev does load them but too late for tpm2.target or the services needed for systemd-repart config with Encrypt=tpm2 to work. Changing TPM drivers to built-in fixed all these issues, and I'm now able to do this since I have the RPMB in kernel patches applied and tee-supplicant is not needed anymore. The issue with TPM drivers as modules was somewhere in the mount of the newly created TPM2 backed filesystem, possibly ConditionSecurity=measured-uki failing. Full boot log in: https://pastebin.com/raw/6xy5x5NP Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Mo, 15.04.24 10:38, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Hi, > > On Fri, Apr 12, 2024 at 05:03:18PM +0300, Aleksandar Kostadinov wrote: > > 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. > > The modules do get loaded but too late in the initramfs stage and something > in the tpm2.target and related service was failing and creating TPM2 encrypted > rootfs fails. I could not figure out at which stage the driver needs to be > loaded, > e.g. > Before: modprobe@tpm_tis_core.service modprobe@tpm_tis.service > modprobe@tpm_ftpm_tee.service > > But I'm also trying to fix the root causes why TPM modules can't be built > into the > kernel so lucky that resolves these issues. Would be nice to know to which > stage > the TPM2 module loading would need to happen though. This should not require manual handling. The driver should be auto-loaded via udev and stuff, like any other driver. Or does the "tpm-ftpm_tee" thing carry no modalias info that autoloads it if some specific hw is around? Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Fri, Apr 12, 2024 at 05:03:18PM +0300, Aleksandar Kostadinov wrote: > 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. The modules do get loaded but too late in the initramfs stage and something in the tpm2.target and related service was failing and creating TPM2 encrypted rootfs fails. I could not figure out at which stage the driver needs to be loaded, e.g. Before: modprobe@tpm_tis_core.service modprobe@tpm_tis.service modprobe@tpm_ftpm_tee.service But I'm also trying to fix the root causes why TPM modules can't be built into the kernel so lucky that resolves these issues. Would be nice to know to which stage the TPM2 module loading would need to happen though. Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
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 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@.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)
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
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 >
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
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'.
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Tue, Feb 20, 2024 at 02:35:27PM +0100, Lennart Poettering wrote: > On Di, 20.02.24 10:24, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Thanks, I will check this. It sounds like optee needs a similar dependency > > generator. > > > > I wonder how many kernel subsystems/drivers which need userspace daemons > > would need systemd side dependency generators. Is it only the ones inside > > initramfs and/or pre-rootfs mount which need special handling? > > Well, systemd to a large part is about getting deps in order, > i.e. start things in the right order but still as parallelized as > possible to make sure we can boot properly, fast. > > For regular (i.e. late boot) services things are easier, since we can > hide various deps via socket activation and services typically just > have fewer deps, but during early boot things always require careful > consideration on what you need to schedulen when. That's hardly > surprising, isn't it? > > TPM stuff in particular is stuff that we want to make use of super > early, because it's inherently part of the boot process to measure > progress and resources we are using. It's what "Measured Boot" after > all means. And that means you need to know what you do, and can't > really escape that. > > > In the end the logic is quite straight forward. If kernel side support is > > there, then a daemon needs to be started before user service start, but > > boot should continue without if kernel support is not detected. > > systemd generators are our way to allow dynamic extension of the > systemd unit dependency graph. It's the fact that you want things > dynamic (i.e. responsive to the fact whether your system has a > specific kind of tpm device/secure enclave) that means you have to do > with a generator. Thanks for the explanation. This issue is clearer now. I'll check into TPM2 generator backport and adding an optee generator. Got distracted by a regression in latest u-boot version (and/or tf-a) while debugging this... Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Di, 20.02.24 10:24, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Thanks, I will check this. It sounds like optee needs a similar dependency > generator. > > I wonder how many kernel subsystems/drivers which need userspace daemons > would need systemd side dependency generators. Is it only the ones inside > initramfs and/or pre-rootfs mount which need special handling? Well, systemd to a large part is about getting deps in order, i.e. start things in the right order but still as parallelized as possible to make sure we can boot properly, fast. For regular (i.e. late boot) services things are easier, since we can hide various deps via socket activation and services typically just have fewer deps, but during early boot things always require careful consideration on what you need to schedulen when. That's hardly surprising, isn't it? TPM stuff in particular is stuff that we want to make use of super early, because it's inherently part of the boot process to measure progress and resources we are using. It's what "Measured Boot" after all means. And that means you need to know what you do, and can't really escape that. > In the end the logic is quite straight forward. If kernel side support is > there, then a daemon needs to be started before user service start, but > boot should continue without if kernel support is not detected. systemd generators are our way to allow dynamic extension of the systemd unit dependency graph. It's the fact that you want things dynamic (i.e. responsive to the fact whether your system has a specific kind of tpm device/secure enclave) that means you have to do with a generator. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi,
On Mon, Feb 19, 2024 at 01:54:02PM +0300, Andrei Borzenkov wrote:
> On Mon, Feb 19, 2024 at 11:37 AM Mikko Rapeli wrote:
> >
> > Hi,
> >
> > On Fri, Feb 16, 2024 at 11:28:31AM +0200, Mikko Rapeli wrote:
> > > Hi,
> > >
> > > Following up to my previous question which worked around with
> > > Wants: and After: to dev-tpmrm0.device and
> > > tee-supplicant@teepriv0.service,
> > > which don't seem to work fully.
> > >
> > > In short, I want to support devices with and without TPM. The TPM device
> > > can also be a firmware fTPM device which depends on tee-supplicant in
> > > userspace
> > > for RPMB storage.
> > >
> > > If TPM device is found, systemd repart in initramfs will create an
> > > encrypted rootfs
> > > and if not a plaintext ext4 partition.
> > >
> > > Support for TPM devices is ok and drivers are built into kernel. systemd
> > > repart config
> > > for rootfs is:
> > >
> > > [Partition]
> > > Type=root
> > > Weight=100
> > > Format=ext4
> > > Encrypt=tpm2
> > > FactoryReset=yes
> > > MakeDirectories=/boot /usr /home /home/root
> > > # copying etc from build time /usr image
> > > CopyFiles=/usr/etc:/etc
> > >
> > > /usr partition generated at build time is dm-verity protected and contains
> > > /etc which is copied over to newly created rootfs.
> > >
> > > Support for fTPM devices is problematic. First, the kernel support must
> > > be modules
> > > but loading needs to be specially handled after starting tee-supplicant.
> > > For normal
> > > boot udev handles optee detection and triggers
> > > tee-supplicant@teepriv0.service
> > > startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant
> > > and then
> > > loads the kernel module again. After this RPMB works. To do the same in
> > > initramfs, I added
> > > Wants: and After: dependencies from systemd-repart.service,
> > > systemd-cryptsetup@.service,
> > > systemd-pcrmachine.service and systemd-pcrphase-initrd.service:
> > >
> > > After=dev-tpmrm0.device tee-supplicant@teepriv0.service
> > > Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service
> >
> > I think my problems come from:
> >
> > After=tee-supplicant@teepriv0.service
> > Wants=tee-supplicant@teepriv0.service
> >
> > Basically tee-supplicant should only be started if /dev/teepriv* device node
> > is available. Then in my case with fTPM devices, all TPM using and encrypted
> > rootfs creating services need to depend on the service which starts
> > tee-supplicant
> > but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then
> > tee-supplicant
> > should not be started and the dependencies to it should not exist either.
> >
>
> The standard way to start a unit when a device becomes available is to
> set SYSTEMD_WANTS udev property for this device.
Yes this is set, but only to:
KERNEL=="teepriv[0-9]*", MODE="0660", OWNER="root", GROUP="teeclnt", \
TAG+="systemd", ENV{SYSTEMD_WANTS}+="tee-supplicant@%k.service"
Can I change the Wants: and Before: rules from udev rules?
After backporting patches for tpm2.target, this service would need to run
before tpm2.target completes.
> > How should this dependency be expressed in systemd services?
> >
> > Can tee-supplicant@.service include:
> >
> > Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
> > systemd-pcrmachine.service
> > WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service
> > systemd-pcrmachine.service
> >
>
> If those service has to be started only if tee-supplicant is also
> started, this is backward. tee-supplicant@ needs to pull in these
> services, not another way round.
Yes, this is backwards because I'm trying to make optee support optional.
Lennart suggest using the dependency generators like for TPM2 devices.
Hardcoding the dependencies from systemd-pcrphase.service etc to
tee-supplicant@teepriv0.service currently works but only for devices
with optee.
Cheers,
-Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Mon, Feb 19, 2024 at 11:53:14AM +0100, Lennart Poettering wrote: > On Mo, 19.02.24 10:36, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > > After=dev-tpmrm0.device tee-supplicant@teepriv0.service > > > Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service > > > > I think my problems come from: > > > > After=tee-supplicant@teepriv0.service > > Wants=tee-supplicant@teepriv0.service > > > > Basically tee-supplicant should only be started if /dev/teepriv* device node > > is available. Then in my case with fTPM devices, all TPM using and encrypted > > rootfs creating services need to depend on the service which starts > > tee-supplicant > > but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then > > tee-supplicant > > should not be started and the dependencies to it should not exist > > either. > > Is /dev/teepriv* guaranteed to be available when userspace is invoked? > or is it something that itself requires some kmod loading to show up, > i.e. that "udevadm trigger" causes to load? At the moment yes, but I think supporting tee drivers as modules is also a good idea. > > How should this dependency be expressed in systemd services? > > > > Can tee-supplicant@.service include: > > > > Before=systemd-pcrphase-initrd.service systemd-pcrphase.service > > systemd-pcrmachine.service > > WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service > > systemd-pcrmachine.service > > > > In my testing this does not seem to work inside initramfs. > > > > If systemd-pcrphase-initrd.service systemd-pcrphase.service and > > systemd-pcrmachine.service > > service have After= and Wants= to tee-supplicant@teepriv0.service then > > things work, > > except on boards which have no optee and no /dev/teepriv0 where > > tee-supplicant seems > > be started and fails due to missing optee which breaks the initramfs boot. > > 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 will check this. It sounds like optee needs a similar dependency generator. I wonder how many kernel subsystems/drivers which need userspace daemons would need systemd side dependency generators. Is it only the ones inside initramfs and/or pre-rootfs mount which need special handling? In the end the logic is quite straight forward. If kernel side support is there, then a daemon needs to be started before user service start, but boot should continue without if kernel support is not detected. Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi, On Mon, Feb 19, 2024 at 11:47:52AM +0100, Lennart Poettering wrote: > On Fr, 16.02.24 11:28, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > > Support for fTPM devices is problematic. First, the kernel support must be > > modules > > but loading needs to be specially handled after starting tee-supplicant. > > For normal > > boot udev handles optee detection and triggers > > tee-supplicant@teepriv0.service > > startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant and > > then > > loads the kernel module again. After this RPMB works. To do the same in > > initramfs, I added > > Wants: and After: dependencies from systemd-repart.service, > > systemd-cryptsetup@.service, > > systemd-pcrmachine.service and systemd-pcrphase-initrd.service: > > Kernel module unloading is not supposed to happen in clean > codepaths. It's a debug/development feature, it's not safe to do as > part of regular boot. > > But why do you need an unload a kernel module at all? that smells... Yes, I agree that this smells bad but it's the current optee/ftpm/kernel implementation which requires tee-supplicant in userspace to be running at module load time for RPMB to work. AFAIK there is some work on going to fix this and support RPMB directly from optee kernel drivers. Cheers, -Mikko
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Mon, Feb 19, 2024 at 11:37 AM Mikko Rapeli wrote:
>
> Hi,
>
> On Fri, Feb 16, 2024 at 11:28:31AM +0200, Mikko Rapeli wrote:
> > Hi,
> >
> > Following up to my previous question which worked around with
> > Wants: and After: to dev-tpmrm0.device and tee-supplicant@teepriv0.service,
> > which don't seem to work fully.
> >
> > In short, I want to support devices with and without TPM. The TPM device
> > can also be a firmware fTPM device which depends on tee-supplicant in
> > userspace
> > for RPMB storage.
> >
> > If TPM device is found, systemd repart in initramfs will create an
> > encrypted rootfs
> > and if not a plaintext ext4 partition.
> >
> > Support for TPM devices is ok and drivers are built into kernel. systemd
> > repart config
> > for rootfs is:
> >
> > [Partition]
> > Type=root
> > Weight=100
> > Format=ext4
> > Encrypt=tpm2
> > FactoryReset=yes
> > MakeDirectories=/boot /usr /home /home/root
> > # copying etc from build time /usr image
> > CopyFiles=/usr/etc:/etc
> >
> > /usr partition generated at build time is dm-verity protected and contains
> > /etc which is copied over to newly created rootfs.
> >
> > Support for fTPM devices is problematic. First, the kernel support must be
> > modules
> > but loading needs to be specially handled after starting tee-supplicant.
> > For normal
> > boot udev handles optee detection and triggers
> > tee-supplicant@teepriv0.service
> > startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant and
> > then
> > loads the kernel module again. After this RPMB works. To do the same in
> > initramfs, I added
> > Wants: and After: dependencies from systemd-repart.service,
> > systemd-cryptsetup@.service,
> > systemd-pcrmachine.service and systemd-pcrphase-initrd.service:
> >
> > After=dev-tpmrm0.device tee-supplicant@teepriv0.service
> > Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service
>
> I think my problems come from:
>
> After=tee-supplicant@teepriv0.service
> Wants=tee-supplicant@teepriv0.service
>
> Basically tee-supplicant should only be started if /dev/teepriv* device node
> is available. Then in my case with fTPM devices, all TPM using and encrypted
> rootfs creating services need to depend on the service which starts
> tee-supplicant
> but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then
> tee-supplicant
> should not be started and the dependencies to it should not exist either.
>
The standard way to start a unit when a device becomes available is to
set SYSTEMD_WANTS udev property for this device.
> How should this dependency be expressed in systemd services?
>
> Can tee-supplicant@.service include:
>
> Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
> systemd-pcrmachine.service
> WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service
> systemd-pcrmachine.service
>
If those service has to be started only if tee-supplicant is also
started, this is backward. tee-supplicant@ needs to pull in these
services, not another way round.
> In my testing this does not seem to work inside initramfs.
>
> If systemd-pcrphase-initrd.service systemd-pcrphase.service and
> systemd-pcrmachine.service
> service have After= and Wants= to tee-supplicant@teepriv0.service then things
> work,
> except on boards which have no optee and no /dev/teepriv0 where
> tee-supplicant seems
> be started and fails due to missing optee which breaks the initramfs boot.
>
> Cheers,
>
> -Mikko
>
> > The base tee-supplicant@.service is:
> >
> > [Unit]
> > Description=TEE Supplicant on %i
> > # Needs to be started earlier
> > DefaultDependencies=no
> > Conflicts=shutdown.target initrd-switch-root.target
> > Before=local-fs-pre.target cryptsetup-pre.target cryptsetup.target
> > shutdown.target initrd-switch-root.target systemd-sysext.service
> > Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
> > systemd-pcrmachine.service
> >
> > [Service]
> > User=root
> > EnvironmentFile=-@sysconfdir@/default/tee-supplicant
> > ExecStartPre=-@sbindir@/modprobe -r tpm_ftpm_tee
> > ExecStartPre=@sbindir@/create-tee-supplicant-env
> > @localstatedir@/run/tee-supplicant.env
> > ExecStart=/bin/sh -c "if [ -c /dev/teepriv0 ]; then
> > @sbindir@/tee-supplicant $RPMB_CID $OPTARGS; fi"
> > ExecStartPost=-/bin/sh -c "while [ ! $(pgrep tee-supplicant) ]; do sleep
> > 0.1; done; /sbin/modprobe tpm_ftpm_tee"
> > ExecStop=-/sbin/modprobe -r tpm_ftpm_tee
> >
> > [Install]
> > # fTPM encrypted filesystems, needs to start in initrd stage
> > WantedBy=local-fs-pre.target
> >
> > These seem to work for devices with and without TPM, but on devices with
> > missing optee
> > and /dev/teepriv0 not. The missing TPM device is detected after timeout,
> > which is ok,
> > and the fallback to unencrypted ext4 happens since systemd-repart.service
> > has:
> >
> > ExecStart=/bin/sh -c "/usr/bin/test -c /dev/tpmrm0 &&
> > /usr/bin/systemd-repart --dry-run=no
> > --definitions=${nonarch_libdir}/repart.d/ || /usr/bin/systemd-repart
>
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Mo, 19.02.24 10:36, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > > After=dev-tpmrm0.device tee-supplicant@teepriv0.service > > Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service > > I think my problems come from: > > After=tee-supplicant@teepriv0.service > Wants=tee-supplicant@teepriv0.service > > Basically tee-supplicant should only be started if /dev/teepriv* device node > is available. Then in my case with fTPM devices, all TPM using and encrypted > rootfs creating services need to depend on the service which starts > tee-supplicant > but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then > tee-supplicant > should not be started and the dependencies to it should not exist > either. Is /dev/teepriv* guaranteed to be available when userspace is invoked? or is it something that itself requires some kmod loading to show up, i.e. that "udevadm trigger" causes to load? > How should this dependency be expressed in systemd services? > > Can tee-supplicant@.service include: > > Before=systemd-pcrphase-initrd.service systemd-pcrphase.service > systemd-pcrmachine.service > WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service > systemd-pcrmachine.service > > In my testing this does not seem to work inside initramfs. > > If systemd-pcrphase-initrd.service systemd-pcrphase.service and > systemd-pcrmachine.service > service have After= and Wants= to tee-supplicant@teepriv0.service then things > work, > except on boards which have no optee and no /dev/teepriv0 where > tee-supplicant seems > be started and fails due to missing optee which breaks the initramfs boot. 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. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
On Fr, 16.02.24 11:28, Mikko Rapeli (mikko.rap...@linaro.org) wrote: > Support for fTPM devices is problematic. First, the kernel support must be > modules > but loading needs to be specially handled after starting tee-supplicant. For > normal > boot udev handles optee detection and triggers tee-supplicant@teepriv0.service > startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant and > then > loads the kernel module again. After this RPMB works. To do the same in > initramfs, I added > Wants: and After: dependencies from systemd-repart.service, > systemd-cryptsetup@.service, > systemd-pcrmachine.service and systemd-pcrphase-initrd.service: Kernel module unloading is not supposed to happen in clean codepaths. It's a debug/development feature, it's not safe to do as part of regular boot. But why do you need an unload a kernel module at all? that smells... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi,
On Fri, Feb 16, 2024 at 11:28:31AM +0200, Mikko Rapeli wrote:
> Hi,
>
> Following up to my previous question which worked around with
> Wants: and After: to dev-tpmrm0.device and tee-supplicant@teepriv0.service,
> which don't seem to work fully.
>
> In short, I want to support devices with and without TPM. The TPM device
> can also be a firmware fTPM device which depends on tee-supplicant in
> userspace
> for RPMB storage.
>
> If TPM device is found, systemd repart in initramfs will create an encrypted
> rootfs
> and if not a plaintext ext4 partition.
>
> Support for TPM devices is ok and drivers are built into kernel. systemd
> repart config
> for rootfs is:
>
> [Partition]
> Type=root
> Weight=100
> Format=ext4
> Encrypt=tpm2
> FactoryReset=yes
> MakeDirectories=/boot /usr /home /home/root
> # copying etc from build time /usr image
> CopyFiles=/usr/etc:/etc
>
> /usr partition generated at build time is dm-verity protected and contains
> /etc which is copied over to newly created rootfs.
>
> Support for fTPM devices is problematic. First, the kernel support must be
> modules
> but loading needs to be specially handled after starting tee-supplicant. For
> normal
> boot udev handles optee detection and triggers tee-supplicant@teepriv0.service
> startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant and
> then
> loads the kernel module again. After this RPMB works. To do the same in
> initramfs, I added
> Wants: and After: dependencies from systemd-repart.service,
> systemd-cryptsetup@.service,
> systemd-pcrmachine.service and systemd-pcrphase-initrd.service:
>
> After=dev-tpmrm0.device tee-supplicant@teepriv0.service
> Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service
I think my problems come from:
After=tee-supplicant@teepriv0.service
Wants=tee-supplicant@teepriv0.service
Basically tee-supplicant should only be started if /dev/teepriv* device node
is available. Then in my case with fTPM devices, all TPM using and encrypted
rootfs creating services need to depend on the service which starts
tee-supplicant
but only if /dev/teepriv0 exists. If teepriv0 doesn't exist, then tee-supplicant
should not be started and the dependencies to it should not exist either.
How should this dependency be expressed in systemd services?
Can tee-supplicant@.service include:
Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
systemd-pcrmachine.service
WantedBy=systemd-pcrphase-initrd.service systemd-pcrphase.service
systemd-pcrmachine.service
In my testing this does not seem to work inside initramfs.
If systemd-pcrphase-initrd.service systemd-pcrphase.service and
systemd-pcrmachine.service
service have After= and Wants= to tee-supplicant@teepriv0.service then things
work,
except on boards which have no optee and no /dev/teepriv0 where tee-supplicant
seems
be started and fails due to missing optee which breaks the initramfs boot.
Cheers,
-Mikko
> The base tee-supplicant@.service is:
>
> [Unit]
> Description=TEE Supplicant on %i
> # Needs to be started earlier
> DefaultDependencies=no
> Conflicts=shutdown.target initrd-switch-root.target
> Before=local-fs-pre.target cryptsetup-pre.target cryptsetup.target
> shutdown.target initrd-switch-root.target systemd-sysext.service
> Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
> systemd-pcrmachine.service
>
> [Service]
> User=root
> EnvironmentFile=-@sysconfdir@/default/tee-supplicant
> ExecStartPre=-@sbindir@/modprobe -r tpm_ftpm_tee
> ExecStartPre=@sbindir@/create-tee-supplicant-env
> @localstatedir@/run/tee-supplicant.env
> ExecStart=/bin/sh -c "if [ -c /dev/teepriv0 ]; then @sbindir@/tee-supplicant
> $RPMB_CID $OPTARGS; fi"
> ExecStartPost=-/bin/sh -c "while [ ! $(pgrep tee-supplicant) ]; do sleep 0.1;
> done; /sbin/modprobe tpm_ftpm_tee"
> ExecStop=-/sbin/modprobe -r tpm_ftpm_tee
>
> [Install]
> # fTPM encrypted filesystems, needs to start in initrd stage
> WantedBy=local-fs-pre.target
>
> These seem to work for devices with and without TPM, but on devices with
> missing optee
> and /dev/teepriv0 not. The missing TPM device is detected after timeout,
> which is ok,
> and the fallback to unencrypted ext4 happens since systemd-repart.service has:
>
> ExecStart=/bin/sh -c "/usr/bin/test -c /dev/tpmrm0 && /usr/bin/systemd-repart
> --dry-run=no --definitions=${nonarch_libdir}/repart.d/ ||
> /usr/bin/systemd-repart --dry-run=no
> --definitions=${nonarch_libdir}/repart.d_notpm/"
>
> But the missing optee and /dev/teepriv0 causes issues where
> tee-supplicant@teepriv0.service gets
> started in initramfs stage but since optee is not found from firmware
> tee-supplicant exits with error.
>
> So what could be done better or correctly?
>
> The problematic part is to run these tee-supplicant and tpm_ftpm_tee loading
> steps
> only when /dev/teepriv0 is available and early enough for TPM2 dependencies
> to work
> for systemd.
>
> Should I rather setup a dedicated service for initramfs
[systemd-devel] Issues supporting systems with and without TPM and firmware TPM (was Re: Handle device node timeout?)
Hi,
Following up to my previous question which worked around with
Wants: and After: to dev-tpmrm0.device and tee-supplicant@teepriv0.service,
which don't seem to work fully.
In short, I want to support devices with and without TPM. The TPM device
can also be a firmware fTPM device which depends on tee-supplicant in userspace
for RPMB storage.
If TPM device is found, systemd repart in initramfs will create an encrypted
rootfs
and if not a plaintext ext4 partition.
Support for TPM devices is ok and drivers are built into kernel. systemd repart
config
for rootfs is:
[Partition]
Type=root
Weight=100
Format=ext4
Encrypt=tpm2
FactoryReset=yes
MakeDirectories=/boot /usr /home /home/root
# copying etc from build time /usr image
CopyFiles=/usr/etc:/etc
/usr partition generated at build time is dm-verity protected and contains
/etc which is copied over to newly created rootfs.
Support for fTPM devices is problematic. First, the kernel support must be
modules
but loading needs to be specially handled after starting tee-supplicant. For
normal
boot udev handles optee detection and triggers tee-supplicant@teepriv0.service
startup which unloads tpm_ftpm_tee kernel module, starts tee-supplicant and then
loads the kernel module again. After this RPMB works. To do the same in
initramfs, I added
Wants: and After: dependencies from systemd-repart.service,
systemd-cryptsetup@.service,
systemd-pcrmachine.service and systemd-pcrphase-initrd.service:
After=dev-tpmrm0.device tee-supplicant@teepriv0.service
Wants=dev-tpmrm0.device tee-supplicant@teepriv0.service
The base tee-supplicant@.service is:
[Unit]
Description=TEE Supplicant on %i
# Needs to be started earlier
DefaultDependencies=no
Conflicts=shutdown.target initrd-switch-root.target
Before=local-fs-pre.target cryptsetup-pre.target cryptsetup.target
shutdown.target initrd-switch-root.target systemd-sysext.service
Before=systemd-pcrphase-initrd.service systemd-pcrphase.service
systemd-pcrmachine.service
[Service]
User=root
EnvironmentFile=-@sysconfdir@/default/tee-supplicant
ExecStartPre=-@sbindir@/modprobe -r tpm_ftpm_tee
ExecStartPre=@sbindir@/create-tee-supplicant-env
@localstatedir@/run/tee-supplicant.env
ExecStart=/bin/sh -c "if [ -c /dev/teepriv0 ]; then @sbindir@/tee-supplicant
$RPMB_CID $OPTARGS; fi"
ExecStartPost=-/bin/sh -c "while [ ! $(pgrep tee-supplicant) ]; do sleep 0.1;
done; /sbin/modprobe tpm_ftpm_tee"
ExecStop=-/sbin/modprobe -r tpm_ftpm_tee
[Install]
# fTPM encrypted filesystems, needs to start in initrd stage
WantedBy=local-fs-pre.target
These seem to work for devices with and without TPM, but on devices with
missing optee
and /dev/teepriv0 not. The missing TPM device is detected after timeout, which
is ok,
and the fallback to unencrypted ext4 happens since systemd-repart.service has:
ExecStart=/bin/sh -c "/usr/bin/test -c /dev/tpmrm0 && /usr/bin/systemd-repart
--dry-run=no --definitions=${nonarch_libdir}/repart.d/ ||
/usr/bin/systemd-repart --dry-run=no
--definitions=${nonarch_libdir}/repart.d_notpm/"
But the missing optee and /dev/teepriv0 causes issues where
tee-supplicant@teepriv0.service gets
started in initramfs stage but since optee is not found from firmware
tee-supplicant exits with error.
So what could be done better or correctly?
The problematic part is to run these tee-supplicant and tpm_ftpm_tee loading
steps
only when /dev/teepriv0 is available and early enough for TPM2 dependencies to
work
for systemd.
Should I rather setup a dedicated service for initramfs which emulates
Wants: and After: for dev-tpmrm0.device and tee-supplicant@teepriv0.service?
Thanks in advance,
-Mikko
