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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 20.02.24 10:24, Mikko Rapeli (mikko.rapeli@xxxxxxxxxx) wrote:

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

Well, systemd to a large part is about getting deps in order,
i.e. start things in the right order but still as parallelized as
possible to make sure we can boot properly, fast.

For regular (i.e. late boot) services things are easier, since we can
hide various deps via socket activation and services typically just
have fewer deps, but during early boot things always require careful
consideration on what you need to schedulen when. That's hardly
surprising, isn't it?

TPM stuff in particular is stuff that we want to make use of super
early, because it's inherently part of the boot process to measure
progress and resources we are using. It's what "Measured Boot" after
all means. And that means you need to know what you do, and can't
really escape that.

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

systemd generators are our way to allow dynamic extension of the
systemd unit dependency graph. It's the fact that you want things
dynamic (i.e. responsive to the fact whether your system has a
specific kind of tpm device/secure enclave) that means you have to do
with a generator.

Lennart

--
Lennart Poettering, Berlin