On Mon, 22 Apr 2024 at 17:22, Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> wrote: > > On Mon, 22 Apr 2024 at 17:31, James Bottomley > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > On Mon, 2024-04-22 at 16:54 +0300, Ilias Apalodimas wrote: > > > Hi James > > > > > > On Mon, 22 Apr 2024 at 16:38, James Bottomley > > > <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > > > > > > > On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote: > > > > > Hi all, > > > > > > > > > > On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli > > > > > <mikko.rapeli@xxxxxxxxxx> > > > > > wrote: > > > > > > > > > > > > Hi, > > > > > > > > > > > > On Mon, Apr 22, 2024 at 08:42:41AM -0400, James Bottomley > > > > > > wrote: > > > > > > > On Mon, 2024-04-22 at 14:27 +0300, Mikko Rapeli wrote: > > > > > > > > Userspace needs to know if TPM kernel drivers need to be > > > > > > > > loaded and related services started early in the boot if > > > > > > > > TPM device is used and available. > > > > > > > > > > > > > > This says what but not why. We already have module > > > > > > > autoloading that works correctly for TPM devices, so why is > > > > > > > this needed? > > > > > > > > > > > > > > We do have a chicken and egg problem with IMA in that the TPM > > > > > > > driver needs to be present *before* any filesystem, including > > > > > > > the one the TPM modules would be on, is mounted so executions > > > > > > > can be measured into IMA (meaning that if you use IMA the TPM > > > > > > > drivers must be built in) but this sounds to be something > > > > > > > different. However, because of the IMA problem, most > > > > > > > distributions don't end up compiling TPM drivers as modules > > > > > > > anyway. > > > > > > > > > > > > > > Is what you want simply that tpm modules be loaded earlier? > > > > > > > > > > > > Yes, ealier is the problem. In my specific testing case the > > > > > > machine is qemu arm64 with swtpm with EFI firmware for secure > > > > > > boot and TPM support. > > > > > > > > > > > > Firmware uses TPM and does measurements and thus TPM event log > > > > > > is > > > > > > available on this machine and a bunch of other arm64 boards. > > > > > > Visible in early boot dmesg as TPMEventLog lines like: > > > > > > > > > > > > [ 0.000000] efi: ESRT=0xf0ea5040 TPMFinalLog=0xf0ea9040 > > > > > > RTPROP=0xf0ea7040 SMBIOS=0xf0ea3000 TPMEventLog=0xeb3b3040 > > > > > > INITRD=0xeb3b2040 RNG=0xe5c0f040 MEMRESERVE=0xe5c0e040 > > > > > > > > > > > > Different boards use different TPM HW and drivers so compiling > > > > > > all these in is possible but a bit ugly. systemd recently > > > > > > gained support for a specific tpm2.target which makes TPM > > > > > > support modular and also works with kernel modules for some TPM > > > > > > use cases but not rootfs encryption. > > > > > > > > > > > > In my test case we have a kernel+initramfs uki binary which is > > > > > > loaded by EFI firmware as a secure boot binary. TPM support on > > > > > > various boards is visible in devicetree but not as ACPI table > > > > > > entries. systemd currently detect TPM2 support either via ACPI > > > > > > table /sys/firmware/acpi/tables/TPM2 or TPM entry or via > > > > > > firmware measurement via > > > > > > /sys/kernel/security/tpm0/binary_bios_measurements > > > > > > . > > > > > > > > > > One corner case worth noting here is that scanning the device > > > > > tree won't always work for non-ACPI systems... The reason is that > > > > > a firmware TPM (running in OP-TEE) might or might not have a DT > > > > > entry, since OP-TEE can discover the device dynamically and > > > > > doesn't always rely on a DT entry. > > > > > > > > > > I don't particularly love the idea that an EventLog existence > > > > > automatically means a TPM will be there, but it seems that > > > > > systemd already relies on that and it does solve the problem we > > > > > have. > > > > > > > > Well, quite. That's why the question I was interested in, perhaps > > > > not asked as clearly as it could be is: since all the TPM devices > > > > rely on discovery mechanisms like ACPI or DT or the like which are > > > > ready quite early, should we simply be auto loading the TPM drivers > > > > earlier? > > > > > > This would be an elegant way to solve this and on top of that, we > > > have a single discovery mechanism from userspace -- e.g ls /dev/tpmX. > > > But to answer that we need more feedback from systemd. What 'earlier' > > > means? Autload it from the kernel before we go into launching the > > > initrd? > > > > Right, so this is another timing problem: we can't autoload modules > > *before* they appear in the filesystem and presumably they're on the > > initrd, so auto loading must be post initrd mount (and init execution) > > but otherwise quite early? > > Exactly. But is that enough? > > > > > This might be quite a bit of work. Logically, just moving the matching > > and loading code earlier might work, but we used to have a > > load_default_modules() at the end of init/main.c and it got removed > > (because it only eventually loaded elevator modules) everything is now > > loaded in it's various init routines, so to get, say, TPM ACPI modules > > loaded earlier, we'd have to run the ACPI device matching code earlier > > and so on for every other subsystem ... > > Being the devil's advocate here and as I stated I don't love this but ... > The kernel isn't technically doing anything wrong. We just expose an > *existing* EFI config table. The kernel also exposes filesystems so > people are free to do rm -rf *. > The fact that applications might use it as a means of "oh there's > probably a TPM" shouldn't be the end of the world. On top of that, > since it's an EFI config table we can keep it around and never break > any ABIs we create to userspace. If in the future we find a better > way, userspace can use that? > > So perhaps this is ok as long as make sure we understand why systemd > needs it that early? > What I would like to know is which API systemd is attempting to use, and which -apparently- may never become available if no TPM is exposed by the kernel. Ideally, we should be able to take inspiration from the probe deferral work, and return -EAGAIN to convey that it is too early to signal either success or permanent failure. Exposing random firmware assets directly to user space to make guesses about this doesn't seem like a very robust approach to this issue.
