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: <ZipcXqpbEkwkXrMI@gardel-login>
Date: Thu, 25 Apr 2024 15:36:30 +0200
From: Lennart Poettering <mzxreary@...inter.de>
To: Ilias Apalodimas <ilias.apalodimas@...aro.org>
Cc: Ard Biesheuvel <ardb@...nel.org>,
	James Bottomley <James.Bottomley@...senpartnership.com>,
	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 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?

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?

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?

Lennart

--
Lennart Poettering, Berlin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ