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 01:54:02PM +0300, Andrei Borzenkov wrote:
> On Mon, Feb 19, 2024 at 11:37 AM Mikko Rapeli <mikko.rapeli@xxxxxxxxxx> 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