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

[Mikko Rapeli <mikko.rapeli@xxxxxxxxxx>]

Hi,

On Fri, May 24, 2024 at 10:20:22AM +0200, Lennart Poettering wrote:
> On Fr, 24.05.24 10:12, Lennart Poettering (lennart@xxxxxxxxxxxxxx) wrote:
> 
> > 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
> 
> So, I looked at the man page for that daemon:
> 
> https://manpages.debian.org/testing/tee-supplicant/tee-supplicant.8.en.html
> 
> This seems like the service is simply not suitable for running in the
> initrd, i.e. it stores its data in /var/lib/optee-client/data/tee, but
> /var/ is only available in late boot. During the initrd and even after
> the initrd→host transition, until local-fs.target and
> systemd-remount-fs.service have been invoked /var/ is not available.
> 
> Hence, what you are trying to do is not going to fly: you need to move
> the service to early boot for disk encryption to work, but the service
> wants to store stuff on the disk, hence only can run after disk
> encryption succeeded. That means it simply doesn't work out.
> 
> (Except of course if that man page is completely out-of-date and the
> service is nowadays fine with running with just /run/ around, and
> without touching /var/ whatsoever).
> 
> (Also, the thing looks fishy generally, as it references /lib/, but
> that's a legacy dir, in systemd we nowadays require merged /usr/ and
> do not supported separate /lib/ hence)

Thanks for the check. I think the documentation is a bit out of date.
For some use cases, like this one with firmware TPM in optee, tee-supplicant
can run in initrd and the storage isn't needed. The storage is used
possibly for RPMB emulation if HW doesn't support it, and in this case HW does
support it. I'm also running with kernel and optee changes from
https://lore.kernel.org/lkml/20240507091619.2208810-1-jens.wiklander@xxxxxxxxxx/
which enable RPMB without any tee-supplicant needs in userspace, but sadly
for the fTPM use case the initial optee RPC setup is current done by tee-supplicant
in userspace. That bit should IMO be moved to the kernel. It's just an allocation of
a memory buffer and calling an ioctl into optee kernel driver.

I'm trying to replace our custom initrd shell script
https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/main/meta-ledge-secure/recipes-ledge/images/files/init.ledge?ref_type=heads
with systemd based configuration for initrd and fixing all the secure boot related
gaps while at it: adding dm-verity /usr partition, using uki to sign both kernel
and initrd image, and dm-verity hash, with uefi secure boot keys, generating rootfs on first
boot with TPM backed encryption though falling back to non-encrypted rootfs if TPM devices is
not found etc.

Cheers,

-Mikko