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: <3bc70b659c1c86c0f08c6d91a6d894ce58825e04.camel@HansenPartnership.com>
Date: Mon, 04 Nov 2024 08:21:50 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: "Daniel P. Smith" <dpsmith@...rtussolutions.com>, Ard Biesheuvel
	 <ardb@...nel.org>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, x86@...nel.org, Ross Philipson
 <ross.philipson@...cle.com>, Thomas Gleixner <tglx@...utronix.de>, Peter
 Huewe <peterhuewe@....de>, Jason Gunthorpe <jgg@...pe.ca>, "open list:TPM
 DEVICE DRIVER" <linux-integrity@...r.kernel.org>, open list
 <linux-kernel@...r.kernel.org>,  trenchboot-devel@...glegroups.com
Subject: Re: [RFC PATCH 0/4] Alternative TPM patches for Trenchboot

On Mon, 2024-11-04 at 07:19 -0500, Daniel P. Smith wrote:
> On 11/4/24 06:55, 'Ard Biesheuvel' via trenchboot-devel wrote:
[...]
> > I was referring specifically to the read-write sysfs node that
> > permits user space to update the default TPM locality. Does it need
> > to be writable? And does it need to exist at all?

This was my question here, which never got answered as well:

https://lore.kernel.org/linux-integrity/685f3f00ddf88e961e2d861b7c783010774fe19d.camel@HansenPartnership.com/

> Right, sorry. As I recall, that was introduce due to the sequence of
> how the TPM driver handled locality, moving back to Locality 0 after
> done sending cmds. In the Oracle implementation, the initramfs takes 
> integrity measurements of the environment it is about to kexec into,
> eg.  target kernel, initramfs, file system, etc. Some of these
> measurements should go into PCR 17 and PCR 18, which requires
> Locality 2 to be able extend those PCRs. If the slmodule is able to
> set the locality for all PCR extends coming from user space to be
> Locality 2, that removes the current need for it.

Well, no, that's counter to the desire to have user space TPM commands
and kernel space TPM commands in different localities.  I thought the
whole point of having locality restricted PCRs is so that only trusted
entities (i.e. those able to access the higher locality) could extend
into them.  If you run every TPM command, regardless of source, in the
trusted locality, that makes the extends accessible to everyone and
thus destroys the trust boundary.

It also doesn't sound like the above that anything in user space
actually needs this facility.  The measurements of kernel and initramfs
are already done by the boot stub (to PCR9, but that could be changed)
so we could do it all from the trusted entity.

Regards,

James


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ