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. /Ilias > If either one of these exist, > then systemd evaluates ConditionSecurity=measured-uki in services correctly and > rolls out TPM services, cryptsetup etc. But the ACPI table entry for TPM isn't mandatory > and many boards don't support it. Then latter requies TPM kernel driver to be loaded > before systemd evaluates ConditionSecurity=measured-uki the first time, or basically > the driver needs to be compiled into the kernel. > > In my case the uki initramfs is also based on systemd and does things like > creating a TPM encrypted rootfs and this should work on a number of boards > automatically, and none of the boards have ACPI table entries for TPM2, but > all of them with real, swtpm or fTPM based TPM devices provide the TPM Event Log > to the kernel. Thus systemd could use this as an indicator for TPM support in addition > to the server grade HW standard ACPI table entry. And once this is in place > TPM drivers and module loading work and initramfs can create a TPM backed rootfs > on first boot. The catch is to install needed kernel modules to the initramfs but > after that, all things work nicely. > > Hope this clarifies this change a bit more. > > Cheers, > > -Mikko
