All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.