linux-kernel - Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch early measurements

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: <CALCETrW8jfkvMc2rwCoyiVON25YFVQZWrb4ZFFoUs3zhRV4YEQ@mail.gmail.com>
Date: Thu, 29 Aug 2024 10:26:18 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Matthew Garrett <mjg59@...f.ucam.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, "Daniel P. Smith" <dpsmith@...rtussolutions.com>, 
	"Eric W. Biederman" <ebiederm@...ssion.com>, Eric Biggers <ebiggers@...nel.org>, 
	Ross Philipson <ross.philipson@...cle.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
	linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org, 
	linux-crypto@...r.kernel.org, kexec@...ts.infradead.org, 
	linux-efi@...r.kernel.org, iommu@...ts.linux-foundation.org, mingo@...hat.com, 
	bp@...en8.de, hpa@...or.com, dave.hansen@...ux.intel.com, ardb@...nel.org, 
	James.Bottomley@...senpartnership.com, peterhuewe@....de, jarkko@...nel.org, 
	jgg@...pe.ca, nivedita@...m.mit.edu, herbert@...dor.apana.org.au, 
	davem@...emloft.net, corbet@....net, dwmw2@...radead.org, 
	baolu.lu@...ux.intel.com, kanth.ghatraju@...cle.com, 
	andrew.cooper3@...rix.com, trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch
 early measurements

On Wed, Aug 28, 2024 at 8:25 PM Matthew Garrett <mjg59@...f.ucam.org> wrote:
>
> On Wed, Aug 28, 2024 at 08:17:05PM -0700, Andy Lutomirski wrote:
>
> > Ross et al, can you confirm that your code actually, at least by
> > default and with a monstrous warning to anyone who tries to change the
> > default, caps SHA1 PCRs if SHA256 is available?  And then can we maybe
> > all stop hassling the people trying to develop this series about the
> > fact that they're doing their best with the obnoxious system that the
> > TPM designers gave them?
>
> Presumably this would be dependent upon non-SHA1 banks being enabled?

Of course.  It's also not immediately obvious to me what layer of the
stack should be responsible for capping SHA1 PCRs.  Should it be the
kernel?  Userspace?

It seems like a whole lot of people, for better or for worse, want to
minimize the amount of code that even knows how to compute SHA1
hashes.  I'm not personally convinced I agree with this strategy, but
it is what it is.  And maybe people would be happier if the default
behavior of the kernel is to notice that SHA256 is available and then
cap SHA1 before even asking user code's permission.

--Andy