Re: [PATCH] efi: expose TPM event log to userspace via sysfs

[Ilias Apalodimas]

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