Received-SPF: pass (google.com: domain of linux-kernel+bounces-159945-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Precedence: bulk
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Fri, 26 Apr 2024 14:41:47 +0300
Message-Id: <D0U0Z7L2IWN4.IDJXDHZYHDF5@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, "Ilias Apalodimas"
 <ilias.apalodimas@linaro.org>, "Lennart Poettering"
 <lennart@poettering.net>
Subject: Re: [PATCH] efi: expose TPM event log to userspace via sysfs
From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mikko Rapeli" <mikko.rapeli@linaro.org>, "Ard Biesheuvel"
 <ardb@kernel.org>, <linux-efi@vger.kernel.org>
References: <20240422112711.362779-1-mikko.rapeli@linaro.org>
In-Reply-To: <20240422112711.362779-1-mikko.rapeli@linaro.org>

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=3D0xbd648040 RTPROP=3D0xbd646040 SMBIOS3.=
0=3D0xbe6ad000 TPMEventLog=3D0xbd5f9040 INITRD=3D0xbd5f7040 RNG=3D0xbd5f604=
0  MEMRESERVE=3D0xbd5f5040
> 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=3D0xbd5f9040
> root@trs-qemuarm64:~# cat /sys/firmware/efi/systab
> SMBIOS3=3D0xbe6ad000
>
> 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.ht=
ml
>
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Lennart Poettering <lennart@poettering.net>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org>

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