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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 15.04.24 17:23, Mikko Rapeli (mikko.rapeli@xxxxxxxxxx) 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.rapeli@xxxxxxxxxx) 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