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

[Mikko Rapeli <mikko.rapeli@xxxxxxxxxx>]

Hi,

On Mon, Feb 19, 2024 at 11:53:14AM +0100, Lennart Poettering wrote:
> On Mo, 19.02.24 10:36, Mikko Rapeli (mikko.rapeli@xxxxxxxxxx) 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