linux-kernel - Re: [PATCH] efi: expose TPM event log to userspace via sysfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66f1d772de1df260a23d2e3c2240e064ee8f67d8.camel@HansenPartnership.com>
Date: Thu, 25 Apr 2024 09:46:35 -0400
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Lennart Poettering <mzxreary@...inter.de>, Ilias Apalodimas
	 <ilias.apalodimas@...aro.org>
Cc: Ard Biesheuvel <ardb@...nel.org>, Mikko Rapeli
 <mikko.rapeli@...aro.org>,  linux-efi@...r.kernel.org,
 linux-kernel@...r.kernel.org,  linux-integrity@...r.kernel.org
Subject: Re: [PATCH] efi: expose TPM event log to userspace via sysfs

On Thu, 2024-04-25 at 15:36 +0200, Lennart Poettering wrote:
> On Do, 25.04.24 14:47, Ilias Apalodimas (ilias.apalodimas@...aro.org)
> wrote:
> 
> > > Yeah, the physical address is of no interest to us. We just need
> > > to
> > > know the existance, and that independently of any actualy tpm
> > > device
> > > having shown up. i.e. existance of
> > > /sys/kernel/security/tpm0/binary_bios_measurements would be good
> > > enough for is if it was available without "tpm0" actually being
> > > around...
> > 
> > IIRC 'binary_bios_measurements' is only created after the TPM
> > drivers
> > probe the device, so that wouldn't work.
> > Ard is right though the TPMEventLog is an EFI stub construct, so
> > exposing this is Linux-specific (and stub-specific).
> > The TPMFinalLog OTOH is described by the TCG spec so exposing that
> > even using the address address would work for systemd
> 
> Hmm, let me ask explicitly: is there any good reason for
> 'binary_bios_measurements' being tied to specific TPM devices? i mean
> it just exposes some firmware-provided memory area, no?

Realistically, no.  The current mechanism for exposing it in securityfs
is tpm chip init, which means it can't appear before a TPM driver
attaches, but there's no real reason why that has to be so.

> So, if the answer to that question is "no", maybe we can just move
> the file to some generic place that is not tied to "tpm0" being
> around, and then make the current file a symlink to that new place
> for compat?

We could just keep it where it is.  I don't believe a log ever appears
at anything other than tpm0 because the event log securityfs attach is
triggered on first tpm appearance, which has to be 0.  So the name is
purely conventional and could be hard coded.  The eventlog code itself
is all linked to the actual chip device (including some of the checks
for event log type---we have to work with both 1.2 and 2.0), but it
should be possible to get the information another way.

James


> i.e. /sys/kernel/security/tpm0/binary_bios_measurements could be a
> symlink to → /sys/kernel/security/binary_bios_measurements and the
> latter could be something the kernel always exposes, before any tpm
> drivers are loaded?