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: <ZsONwsWs3zCln70O@srcf.ucam.org>
Date: Mon, 19 Aug 2024 19:24:02 +0100
From: Matthew Garrett <mjg59@...f.ucam.org>
To: Jarkko Sakkinen <jarkko@...nel.org>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>,
	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,
	jgg@...pe.ca, luto@...capital.net, 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, trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch
 early measurements

On Mon, Aug 19, 2024 at 09:05:47PM +0300, Jarkko Sakkinen wrote:
> On Fri Aug 16, 2024 at 9:41 PM EEST, Matthew Garrett wrote:
> > On Fri, Aug 16, 2024 at 02:22:04PM +0300, Jarkko Sakkinen wrote:
> >
> > > For (any) non-legacy features we can choose, which choices we choose to
> > > support, and which we do not. This is not an oppositive view just saying
> > > how it is, and platforms set of choices is not a selling argument.
> >
> > NIST still permits the use of SHA-1 until 2030, and the most significant 
> > demonstrated weaknesses in it don't seem applicable to the use case 
> > here. We certainly shouldn't encourage any new uses of it, and anyone 
> > who's able to use SHA-2 should be doing that instead, but it feels like 
> > people are arguing about not supporting hardware that exists in the real 
> > world for vibes reasons rather than it being a realistically attackable 
> > weakness (and if we really *are* that concerned about SHA-1, why are we 
> > still supporting TPM 1.2 at all?)
> 
> We are life-supporting TPM 1.2 as long as necessary but neither the
> support is extended nor new features will gain TPM 1.2 support. So
> that is at least my policy for that feature.

But the fact that we support it and provide no warning labels is a 
pretty clear indication that we're not actively trying to prevent people 
from using SHA-1 in the general case. Why is this a different case? 
Failing to support it actually opens an entire separate set of footgun 
opportunities in terms of the SHA-1 banks now being out of sync with the 
SHA-2 ones, so either way we're leaving people open to making poor 
choices.