From: "Jarkko Sakkinen" <jarkko@kernel.org>
To: "Mikko Rapeli" <mikko.rapeli@linaro.org>,
"Ard Biesheuvel" <ardb@kernel.org>, <linux-efi@vger.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
Date: Fri, 26 Apr 2024 14:41:47 +0300 [thread overview]
Message-ID: <D0U0Z7L2IWN4.IDJXDHZYHDF5@kernel.org> (raw)
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=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@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
next prev parent reply other threads:[~2024-04-26 11:41 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-22 11:27 [PATCH] efi: expose TPM event log to userspace via sysfs Mikko Rapeli
2024-04-22 12:42 ` James Bottomley
2024-04-22 13:08 ` Mikko Rapeli
2024-04-22 13:32 ` Ilias Apalodimas
2024-04-22 13:38 ` James Bottomley
2024-04-22 13:54 ` Ilias Apalodimas
2024-04-22 14:31 ` James Bottomley
2024-04-22 15:22 ` Ilias Apalodimas
2024-04-24 17:15 ` Ard Biesheuvel
2024-04-25 8:56 ` Mikko Rapeli
2024-04-25 13:50 ` Jarkko Sakkinen
2024-04-25 9:58 ` Lennart Poettering
2024-04-25 10:36 ` Ard Biesheuvel
2024-04-25 11:13 ` Lennart Poettering
2024-04-25 11:47 ` Ilias Apalodimas
2024-04-25 13:36 ` Lennart Poettering
2024-04-25 13:46 ` James Bottomley
2024-04-25 13:24 ` James Bottomley
2024-04-25 13:39 ` Mikko Rapeli
2024-04-25 13:40 ` Lennart Poettering
2024-04-25 14:01 ` Jarkko Sakkinen
2024-04-26 7:35 ` Jarkko Sakkinen
2024-04-26 7:40 ` Jarkko Sakkinen
2024-04-26 8:19 ` Mikko Rapeli
2024-04-26 8:23 ` Jarkko Sakkinen
2024-04-22 14:57 ` Mikko Rapeli
2024-04-26 11:41 ` Jarkko Sakkinen [this message]
2024-04-26 11:48 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=D0U0Z7L2IWN4.IDJXDHZYHDF5@kernel.org \
--to=jarkko@kernel.org \
--cc=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=lennart@poettering.net \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mikko.rapeli@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).