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? Thanks /Ilias > James >
