[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9f0db589-e7b4-09c0-aed2-588b2a2e1bf5@apertussolutions.com>
Date: Mon, 15 May 2023 17:23:55 -0400
From: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
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,
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 5/9/23 21:21, 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?
I think others have commented as to why SHA-1 is provided.
> And if you absolutely MUST use SHA-1 despite it being insecure, please at least
> don't obfuscate it by calling it simply "SHA".
Apologies that it appears that way to you. Typically when referring to
the family or a subset of the SHA algorithms, SHA-0, SHA-1, SHA-2, and
SHA-3, it is generally accepted to refer to them as the "SHA
algorithms". And this is contrasted to the SM algorithms which the TCG
spec provides for which we have no intentions to support ourselves,
though others are welcome to contribute.
Again, apologies for misunderstanding and thank you for taking the time
to review the series.
v/r,
dps
Powered by blists - more mailing lists