From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Mikko Rapeli <mikko.rapeli@linaro.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
Lennart Poettering <lennart@poettering.net>,
linux-integrity@vger.kernel.org
Subject: Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Date: Mon, 22 Apr 2024 09:38:31 -0400 [thread overview]
Message-ID: <e3038141413e25350f0e53496f7a7af1bf8419cf.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAC_iWjKA-xRH=3FK+=woXsB8AW4+_mVhJhUQnL8iFKxGzOwKiA@mail.gmail.com>
On Mon, 2024-04-22 at 16:32 +0300, Ilias Apalodimas wrote:
> Hi all,
>
> On Mon, 22 Apr 2024 at 16:08, Mikko Rapeli <mikko.rapeli@linaro.org>
> wrote:
> >
> > 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
> > .
>
> One corner case worth noting here is that scanning the device tree
> won't always work for non-ACPI systems... The reason is that a
> firmware TPM (running in OP-TEE) might or might not have a DT entry,
> since OP-TEE can discover the device dynamically and doesn't always
> rely on a DT entry.
>
> I don't particularly love the idea that an EventLog existence
> automatically means a TPM will be there, but it seems that systemd
> already relies on that and it does solve the problem we have.
Well, quite. That's why the question I was interested in, perhaps not
asked as clearly as it could be is: since all the TPM devices rely on
discovery mechanisms like ACPI or DT or the like which are ready quite
early, should we simply be auto loading the TPM drivers earlier?
James
next parent reply other threads:[~2024-04-22 13:38 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240422112711.362779-1-mikko.rapeli@linaro.org>
[not found] ` <6e751959b9056884c1b9d3ba23e303d1737d8763.camel@HansenPartnership.com>
[not found] ` <ZiZhSfgeAdrbnaVL@nuoska>
[not found] ` <CAC_iWjKA-xRH=3FK+=woXsB8AW4+_mVhJhUQnL8iFKxGzOwKiA@mail.gmail.com>
2024-04-22 13:38 ` James Bottomley [this message]
2024-04-22 13:54 ` [PATCH] efi: expose TPM event log to userspace via sysfs 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
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=e3038141413e25350f0e53496f7a7af1bf8419cf.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--cc=lennart@poettering.net \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@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 read-only IMAP folder(s) and NNTP newsgroup(s).