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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 10.06.24 11:19, Lennart Poettering (lennart@xxxxxxxxxxxxxx) wrote:

> 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.

Hmm, so here's an idea how we could hack this in userspace with some
lose coupling between systemd and optee drivers/supplicant:

device nodes on linux can carry xattrs in the "trusted." xattr
namespace. Maybe we can use that to tell systemd-tpm2-generator that way
/dev/tpm0 is not usable without daemon.

i.e.: in systemd-tpm2-generator, we would look for an xattr
"trusted.needs-daemon" on /dev/tpm0. If it's set and non-zero, then
we'll unconditionally enqueue tpm2.target. This would be relatively
nice I think, because it means the information is directly attached to
the device in question (i.e. if for some reason /dev/tpm0 goes away,
then the xattr goes away automatically too), and it would be metainfo
we can attach without udev around already.

This would then mean that something optee supplicant ships would have
to set that xattr. It could do so either in its own optee supplicant C
code, the instant it takes control of the tpm device; or it could do
that via a udev rule that it ships and that matches against the
driver. This rule would have to be included in the initrd so that it
runs there already and sets the xattr, so that when we transition into
the host (where the udev db is flushed out, but the device nodes stick
around) it's set.

Of course, I'd much prefer some proper kernel infra for this all
(i.e. some clear sysfs attr on the tpm device), but such a
userspace-based xattr solution seems to be acceptable to me, if you
want this. Should be a 5-line patch to systemd-tpm2-generator I'd be
willing to merge.

Lennart

--
Lennart Poettering, Berlin