From: Lennart Poettering <mzxreary@0pointer.de>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: Ard Biesheuvel <ardb@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Mikko Rapeli <mikko.rapeli@linaro.org>,
linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-integrity@vger.kernel.org
Subject: Re: [PATCH] efi: expose TPM event log to userspace via sysfs
Date: Thu, 25 Apr 2024 15:40:00 +0200 [thread overview]
Message-ID: <ZipdML5KN6IPenX5@gardel-login> (raw)
In-Reply-To: <f6259f0a28b80db78d28475105ae7f37655a58ee.camel@HansenPartnership.com>
On Do, 25.04.24 09:24, James Bottomley (James.Bottomley@HansenPartnership.com) wrote:
> On Thu, 2024-04-25 at 11:58 +0200, Lennart Poettering wrote:
> [...]
> > General purpose distros typically don't build all TPM drivers into
> > the kernel, but ship some in the initrd instead. Then, udev is
> > responsible for iterating all buses/devices and auto-loading the
> > necessary drivers. Each loaded bus driver might make more devices
> > available for which more drivers then need to be loaded, and so on.
> > Some of the busses are "slow" in the sense that we don't really know
> > a precise time when we know that all devices have now shown up, there
> > might always be slow devices that haven't popped up yet. Iterating
> > through the entire tree of devices in sysfs is often quite slow in
> > itself too, it's one of the most time consuming parts of the boot in
> > fact. This all is done asynchronously hence: we
> > enumerate/trigger/kmod all devices as quickly as we can, but we
> > continue doing other stuff at the same time.
>
> So let me make a suggestion that you can use now. Since all you
> currently care about is the EFI/ACPI device, there is always a single
> sysfs entry that corresponds to that (so you shouldn't need the log
> entry as an indicator):
>
> /sys/bus/acpi/devices/MSFT0101\:00
>
> That link (or a kobject uevent if you prefer to look for that) will
> always appear regardless of whether a driver has attached or not. When
> the driver actually attaches, a driver/ directory will appear where the
> link points.
>
> The device link is added when the acpi scan is initiated as a
> subsys_initcall, which is before all the filesystem initcalls, so it
> should run before the initrd is mounted.
>
> Is this enough for now and we can think about a more generic indicator
> that all drivers have been probed later?
That would only work on ACPI though, but on ACPI we already have a
check that works?
Or to say this differently: how is that different/better from the
check that already exists in systemd, which looks for
/sys/firmware/acpi/tables/TPM2?
Lennart
--
Lennart Poettering, Berlin
next prev parent reply other threads:[~2024-04-25 13:40 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 [this message]
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
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=ZipdML5KN6IPenX5@gardel-login \
--to=mzxreary@0pointer.de \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=ilias.apalodimas@linaro.org \
--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 NNTP newsgroup(s).