On Mon Apr 22, 2024 at 2:27 PM EEST, 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. If EFI firmware has used TPM device > to e.g. measure binaries, then many of them also provide the TPM What are the other uses cases? TPM settings and reset (clear), i.e. machine owner use cases? I think "e.g." is not needed here and it confuses a bit. > log to kernel in addition to the actual TPM device side measurements. > Expose availability of TPM event log to userspace via > /sys/firmware/efi/tpm_log. If the file exists, then firmware > provided a TPM event log to kernel, and userspace init should also > queue TPM module loading and other early boot services for TPM support. > > Enables systemd to support TPM drivers as modules when rootfs is > encrypted with the TPM device. "Enabling systemd" is not an unambiguous sequence of events, as far as I know. Please describe what the changes are done to the kernel, and how they help to enable whatever systemd wants it. This is way too abstract to work as "a pitch". > > Sample output from a arm64 qemu machine with u-boot based EFI firmware > and swtpm: > > root@trs-qemuarm64:~# dmesg|grep TPMEvent > [ 0.000000] efi: TPMFinalLog=0xbd648040 RTPROP=0xbd646040 SMBIOS3.0=0xbe6ad000 TPMEventLog=0xbd5f9040 INITRD=0xbd5f7040 RNG=0xbd5f6040 MEMRESERVE=0xbd5f5040 > root@trs-qemuarm64:~# ls -l /sys/firmware/efi/tpm_log > -r-------- 1 root root 4096 Apr 22 10:31 /sys/firmware/efi/tpm_log > root@trs-qemuarm64:~# cat /sys/firmware/efi/tpm_log > TPMEventLog=0xbd5f9040 > root@trs-qemuarm64:~# cat /sys/firmware/efi/systab > SMBIOS3=0xbe6ad000 > > Other similar information is currently in /sys/firmware/efi/systab but > for new exported variables a one-variable-per-file sysfs interface > is preferred according to comments in systab_show() > drivers/firmware/efi/efi.c > > See also: > https://github.com/systemd/systemd/pull/32314 > https://lists.freedesktop.org/archives/systemd-devel/2024-April/050206.html > > Cc: Ilias Apalodimas <ilias.apalodimas@xxxxxxxxxx> > Cc: Lennart Poettering <lennart@xxxxxxxxxxxxxx> > Signed-off-by: Mikko Rapeli <mikko.rapeli@xxxxxxxxxx> I'd recommend to test this also with hardware. Easy options for ARM are: 1. Raspberry Pi 3B+. It has broken TrustZone that allows supply your own payloads. OP-TEE supports this. 2. Get https://thepihut.com/products/letstrust-tpm-for-raspberry-pi. BR, Jarkko
