[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CSIYAN7SXASE.34Z0FBRCENLAI@suppilovahvero>
Date: Thu, 11 May 2023 01:28:33 +0300
From: "Jarkko Sakkinen" <jarkko@...nel.org>
To: "Eric Biggers" <ebiggers@...nel.org>,
"Ross Philipson" <ross.philipson@...cle.com>
Cc: <linux-kernel@...r.kernel.org>, <x86@...nel.org>,
<linux-integrity@...r.kernel.org>, <linux-doc@...r.kernel.org>,
<linux-crypto@...r.kernel.org>, <iommu@...ts.linux-foundation.org>,
<kexec@...ts.infradead.org>, <linux-efi@...r.kernel.org>,
<dpsmith@...rtussolutions.com>, <tglx@...utronix.de>,
<mingo@...hat.com>, <bp@...en8.de>, <hpa@...or.com>,
<ardb@...nel.org>, <mjg59@...f.ucam.org>,
<James.Bottomley@...senpartnership.com>, <luto@...capital.net>,
<nivedita@...m.mit.edu>, <kanth.ghatraju@...cle.com>,
<trenchboot-devel@...glegroups.com>
Subject: Re: [PATCH v6 06/14] x86: Add early SHA support for Secure Launch
early measurements
On Wed May 10, 2023 at 4:21 AM EEST, Eric Biggers wrote:
> On Thu, May 04, 2023 at 02:50:15PM +0000, Ross Philipson wrote:
> > From: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
> >
> > The SHA algorithms are necessary to measure configuration information into
> > the TPM as early as possible before using the values. This implementation
> > uses the established approach of #including the SHA libraries directly in
> > the code since the compressed kernel is not uncompressed at this point.
> >
> > The SHA code here has its origins in the code from the main kernel:
> >
> > commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1")
> >
> > That code could not be pulled directly into the setup portion of the
> > compressed kernel because of other dependencies it pulls in. The result
> > is this is a modified copy of that code that still leverages the core
> > SHA algorithms.
> >
> > Signed-off-by: Daniel P. Smith <dpsmith@...rtussolutions.com>
> > Signed-off-by: Ross Philipson <ross.philipson@...cle.com>
>
> SHA-1 is insecure. Why are you still using SHA-1? Don't TPMs support SHA-2
> now?
>
> And if you absolutely MUST use SHA-1 despite it being insecure, please at least
> don't obfuscate it by calling it simply "SHA".
AFAIK the TCG specs require for any TPM2 implementation to support both
SHA-1 and SHA-256, so this as a new feature should lock in to the
latter.
BR, Jarkko
Powered by blists - more mailing lists