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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 10.06.24 11:55, Mikko Rapeli (mikko.rapeli@xxxxxxxxxx) wrote:

> > I guess to fix this we have to somehow ensure that after the
> > transition we'll detect that the /dev/tpmrm0 device is not actually
> > usable, and we have to enqueue tpm2.target after all.
> >
> > Is there any reasonable way we can detect this?
> >
> > For example, for this kind of TPM device is there maybe a sysfs
> > attribute file in /sys/class/tpm/tpm0/ or so which tells is whether
> > the device already works, or if it needs some userspace component?
> > Note that at that point udev is not operable anymore/yet hence we
> > cannot just ask the udev db for this.
>
> That's the tricky thing. There does not seem to be a TPM side interface
> for this.

That's kinda sad. Any chance you can work the TPM kernel folks to get
something like this implemented? some sysfs attr on the tpm device
that tells userspace if the thing is currently in a usable state (and
ideally an uevent whenever that state changes). Is optee the only case
where a kernel TPM device needs a userspace component to be running to
be workable? If not, this sounds like something generically useful.

> The optee kernel driver does know that there is no tee-supplicant
> in userspace running. That's why by default the userspace side API of
> optee is keeping the users waiting until tee-supplicant is there. Sadly for
> all kernel side users this is not the default. This simple patch
> converts the ftpm kernel driver use of optee APIs to wait for tee-supplicant
> in userspace, but it sadly hangs the shutdown and reboot and isn't
> recommended by optee maintainer Jens Wiklander
> <jens.wiklander@xxxxxxxxxx>:

Uh, kernelspace blocking on userspace is ugly as fuck. This doesn't
seem like the right approach to me.

> > So I'd expect the TEE service would use sd_notify() to send a
> > "READY=1" notification to the service manager once it did everything
> > so that /dev/tpmrm0 is ready to go. You'd then use Type=notify or
> > Type=notify-reload in the unit file to tell systemd that it shall wait
> > for sd_notify().
>
> Indeed, the tee-supplicant sd_notify() usage is being discussed in:
>
> https://github.com/OP-TEE/optee_client/pull/383

I added some minor comments there.

> > > > Please provide proper boot logs, with debug logging enabled.
> > >
> > > Debug logging is available from here, sadly log is too big to view
> > > nicely on the web page and has to be downloaded:
> > >
> > > https://ledge.validation.linaro.org/scheduler/job/88420
> >
> > This indeed shows that tpm2.target doesn't get enqueued again after
> > the initrd transition. So my educated guess above seems to be right,
> > and we need to find a way now to automatically determine from a TPM
> > device node whether it is ready to use or not. So far we assumed if we
> > have one it was ready to use, but that appears to be incorrect for
> > these TEE devices. So how do we detect this case so that we can delay
> > TPM operations until the thing is working again via the tpm2.target
> > stuff?
>
> Yes, you are correct. Sadly the TPM APIs don't seem to tell this, but maybe
> the optee side could, and maybe optee users like ftpm kernel driver could
> listen to that and for example stop the driver when tee-supplicant goes
> down. This has been worked around in the past by using ftpm drivers
> as modules and unloading the module before tee-supplicant stops in
> init or systemd service scripts. I can add this back in to get things going
> for now, but as you see, supporting TPM kernel drivers as modules would be
> nice with systemd and I'll need to revisit that kernel patch which helps
> to tell systemd that firmware used a TPM device (in the case when
> TPM ACPI table entry is not available, e.g. ARM System Ready IR
> devices).

So in systemd we'd rather only have generic tests, i.e. I am a bit
reluctant to adding support for checking explicitly for optee in
systemd-tpm2-generator, to enqueue tpm2.target always in that case.

However, what you probably could do is write your own little generator
/usr/lib/systemd/system-generators/optee-generator that you ship with
optee supplicant that does something like this:

```
#!/usr/sh
if [ -f /sys/class/optee/some/file ] ; then
        mkdir -p "$1"/sysinit.target.wants/
        ln -sf /usr/lib/systemd/system/tpm2.target "$1"/sysinit.target.wants/tpm2.target
fi
exit 0
```

This would basically be a driver-specific re-implementation of our
generic systemd-tpm2-generator, that knows that when optee/ftpm stuff
is used we *must* schedule tpm2.target in all cases, even if /dev/tpm0
already exists. The sysfs path in the script above I made up of
course, you'd have to find some sysfs file that exists exactly when
the optee/ftpm case applies, and that is available before any kmod is
loaded.

You can make this a shell script as above, but I'd always recommend
trying to keep shell out of the boot process, hence maybe write it in
a better language. Generators run super early during boot, and we have
to wait for all of them to complete before we continue, hence
something reasonably fast would be good, shell sucks for that.

The above would implement the generator interface, i.e.:

https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html

But again, if you can provide us with a generic interface we can
instead just add this to upstream systemd-tpm2-generator and be happy.

Lennart

--
Lennart Poettering, Berlin