Message-ID: <ZiZhSfgeAdrbnaVL@nuoska>
Date: Mon, 22 Apr 2024 16:08:25 +0300
From: Mikko Rapeli <mikko.rapeli@...aro.org>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, linux-efi@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Ilias Apalodimas <ilias.apalodimas@...aro.org>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [PATCH] efi: expose TPM event log to userspace via sysfs

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 . 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

Powered by blists - more mailing lists