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
[systemd-devel] Prerequisites for systemd.volatile=yes
Hi All, I'm trying to use volatile root feature for the first time. This is my /etc/fstab: ``` #system mnt-pt type options dump fsck PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b / ext4 defaults,barrier,noatime,data=ordered 1 1 ``` And systemd grub configs are: systemd_cmdline=net.ifnames=0 plymouth.enable=0 systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes Finally, kernel command is: BOOT_IMAGE=/vmlinuz-6.1.83-1.ph5 root=PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b init=/lib/systemd/systemd ro loglevel=3 quiet net.ifnames=0 plymouth.enable=0 systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes And I regenerated initrd using `mkinitrd` But when I rebooted my vm, it is going to emergency shell and shows /run/initramfs/rdsosreport.txt and I'm not able to get into emergency shell either, it just keeps looping in press Ctrl-D or enter root password prompt and entering root password or pressing Ctrl-D just prompts the same thing again. Can someone assist me on what are the prerequisites for enabling volatile root? - Kernel configs to be enabled - File system types supported - Kernel command line args needed If someone can provide a step by step procedure on how to see this feature in action, it would really help. -- Shedi
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
