Re: tee-supplicant initrd startup before tpm2.target and dev-tpmrm0.device

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 24.05.24 10:10, Mikko Rapeli (mikko.rapeli@xxxxxxxxxx) wrote:

> > > EnvironmentFile=-@sysconfdir@/default/tee-supplicant
> > > ExecStart=@sbindir@/tee-supplicant $OPTARGS
> > >
> > > [Install]
> > > WantedBy=basic.target
> >
> > Usually you'd hook services into "sysinit.target" not
> > "basic.target". The job of "basic.target" is really do combine
> > sysinit.target (i.e. early-boot services), local-fs.target
> > (i.e. local mounts), swaps.target (swaps), sockets.target (well, you
> > guess it), and so on.
> >
> > Hence, if you plug in services, use sysinit.target.
>
> tee-supplicant@.service needs to run early, before rootfs decryption in case of fTPM.
> Would "WantedBy=sysinit.target" and "Before: tpm2.target" be correct
> then?

Well, you want to run it during early boot, hence you should add
DefaultDependencies=no and that should really suffice, given you
actually start the thing via an udev rule.

>
> > > udev rule is:
> > >
> > > KERNEL=="tee[0-9]*", MODE="0660", OWNER="root", GROUP="teeclnt", TAG+="systemd"
> > >
> > > # If a /dev/teepriv[0-9]* device is detected, start an instance of
> > > # tee-supplicant.service with the device name as parameter
> > > KERNEL=="teepriv[0-9]*", MODE="0660", OWNER="root", GROUP="teeclnt", \
> > >     TAG+="systemd", ENV{SYSTEMD_WANTS}+="tee-supplicant@%k.service"
> > >
> > > So basically dev-tpmrm0.device depends on tee-supplicant@teepriv0.service started
> > > on dev-teepriv0.device by udev. How to express this dependency?
> >
> > I am not sure I grok this dependency chain?
> >
> > What do you mean by ordering the service against dev-tpmrm0.device?
> > why would you order this? I mean, when
> > tee-supplicant@teepriv0.service is invoked it will do its thing and
> > synthesize a /dev/tpmrm0, right?
>
> Firmware has optee and an fTPM trusted app. In kernel we have the fTPM driver
> but all of these depend also on the userspace tee-supplicant to handle optee IPC setup
> and possibly RPMB emulation (in my case I have kernel patches for this, and native
> support on the platforms). So the fTPM TA in optee only enumerates after tee-supplicant
> has been started, and this in turn triggers fTPM kernel module
> loading with udev.

I am not sure I can parse all that, but it seems the only deps you
need are:

1. pull in tee-supplicant@%k.service when the tee device shows up via
   the udev rule
2. make sure tee-supplicant@.service has DefaultDependencies=no so
   that it can be started in early boot.
3. Make sure that tee-supplicant@.service has After=dev-%i.device and
   Wants=dev-%i.device – this part is kinda optional, given you pull
   in the service by default only via that udev rule, and thus the
   device has already shown up. Having these two deps explicitly is
   still kinda useful though in case a user does "systemctl start
   tee-suppliant@teepriv0.service" manually or so, since it makes sure
   we'll wait for the backing device to show up.

And that's really all.

To summarize, a unit file like this:

    [Unit]
    Description=TEE Supplicant on %i
    Documentation=man:tee-supplicant(8)
    DefaultDependencies=no
    After=dev-%i.device
    Wants=dev-%i.device
    Conflicts=shutdown.target
    Before=sysinit.target shutdown.target

    [Service]
    ExecStart=@sbindir@/tee-supplicant -d /dev/%I

Together with a udev rule:

    KERNEL=="teepriv[0-9]*", MODE="0660", TAG+="systemd", ENV{SYSTEMD_WANTS}+="tee-supplicant@%k.service"

And that should make things work. (Well, I have no experience with any
of this, I never touched such a platform, the above is made up without
ever having played with this.)

If you want the ability to enable/disable the service, you could add
an indirection via a target unit, and then add an [Install]
section. But I am not sure that makes too much sense, given that you
want this stuff in the initrd already?  services that can be
enabled/disabled are usually stuff for the main system, not for the
initrd.

> > This shows an ordering cycle. Address that first. If you have an
> > ordering cycle systemd will drop jobs from the initial transactions in
> > an attempt to fix it, but it's not always clear that the one it drops
> > it the best one to drop.
>
> Indeed, these ordering problems may be the root cause.

So the ordering is probably because the missing DefaultDependencies=no

> > The logs do not show that your "tee-supplicant@.service" unit gets
> > enqueued. So are you sure your udev rule even works?
>
> The udev rule works. With debug logs I see:
>
> https://ledge.validation.linaro.org/scheduler/job/87556
>
> [0;38;5;245mtee-supplicant@teepriv0.service: starting held back,
> waiting for: basic.target[0m

Yupp, that's the DefaultDependencies=no thing.

> So I think I need to disable the default dependencies with DefaultDependencies=no
> With my limited understanding I think I would also need the tpm2.target to wait for
> tee-supplicant startup. "WantedBy=sysinit.target tpm2.target" would do it?
> Or alternatively in tpm2.target
>
> After=dev-tpmrm0.device dev-teepriv0.device
> Wants=dev-tpmrm0.device dev-teepriv0.device

Why should tpm2.target wait for tee-supplicant startup though? it
should be enough for the /dev/tpmrm0 device to materalize, no? And
that hapens when tee-supplicant does its thing, hence there's no need
to explicitly wait for that, is there?

Lennart

--
Lennart Poettering, Berlin