[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <D3KUEGW4Q63K.NEFOY5C6ZG2O@kernel.org>
Date: Tue, 20 Aug 2024 18:26:31 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Matthew Garrett" <mjg59@...f.ucam.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 9:24 PM EEST, Matthew Garrett wrote:
> 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.
This is a fair and enclosing argument. I get where you are coming from
now. Please as material for the commit message.
BR, Jarkko
Powered by blists - more mailing lists