Re: [RFC PATCH 03/12] x86: Add early SHA support for Secure Launch early measurements

From: "Daniel P. Smith" <dpsmith@apertussolutions.com>
To: Andy Lutomirski <luto@kernel.org>,
	Ross Philipson <ross.philipson@oracle.com>
Cc: LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	trenchboot-devel@googlegroups.com
Subject: Re: [RFC PATCH 03/12] x86: Add early SHA support for Secure Launch early measurements
Date: Thu, 26 Mar 2020 18:49:49 -0400	[thread overview]
Message-ID: <b3e7003e-9019-5402-0205-0248a4c24584@apertussolutions.com> (raw)
In-Reply-To: <CALCETrUoA9dgi2omjePtzjL9=5AqHKhy57UksnxbohZVdLo_pQ@mail.gmail.com>

On 3/25/20 11:44 PM, Andy Lutomirski wrote:
> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
> <ross.philipson@oracle.com> wrote:
>>
>> From: "Daniel P. Smith" <dpsmith@apertussolutions.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 SHA1 code here has its origins in the code in
>> include/crypto/sha1_base.h. That code could not be pulled directly into
>> the setup portion of the compressed kernel because of other dependencies
>> it pulls in. So this is a modified copy of that code that still leverages
>> the core SHA1 algorithm.
>>
>> Signed-off-by: Daniel P. Smith <dpsmith@apertussolutions.com>
>> ---
>>  arch/x86/Kconfig                        |  24 +++
>>  arch/x86/boot/compressed/Makefile       |   4 +
>>  arch/x86/boot/compressed/early_sha1.c   | 104 ++++++++++++
>>  arch/x86/boot/compressed/early_sha1.h   |  17 ++
>>  arch/x86/boot/compressed/early_sha256.c |   6 +
>>  arch/x86/boot/compressed/early_sha512.c |   6 +
>>  include/linux/sha512.h                  |  21 +++
>>  lib/sha1.c                              |   4 +
>>  lib/sha512.c                            | 209 ++++++++++++++++++++++++
>>  9 files changed, 395 insertions(+)
>>  create mode 100644 arch/x86/boot/compressed/early_sha1.c
>>  create mode 100644 arch/x86/boot/compressed/early_sha1.h
>>  create mode 100644 arch/x86/boot/compressed/early_sha256.c
>>  create mode 100644 arch/x86/boot/compressed/early_sha512.c
>>  create mode 100644 include/linux/sha512.h
>>  create mode 100644 lib/sha512.c
>>
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 7f3406a9948b..f37057d3ce9f 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -2025,6 +2025,30 @@ config SECURE_LAUNCH
>>           of all the modules and configuration information used for
>>           boooting the operating system.
>>
>> +choice
>> +       prompt "Select Secure Launch Algorithm for TPM2"
>> +       depends on SECURE_LAUNCH
>> +
>> +config SECURE_LAUNCH_SHA1
>> +       bool "Secure Launch TPM2 SHA1"
>> +       help
>> +         When using Secure Launch and TPM2 is present, use SHA1 hash
>> +         algorithm for measurements.
>> +
> 
> I'm surprised this is supported at all.  Why allow SHA1?
> 

The SHA1 code is already there for TPM1.2 and it is a valid supported
mode for TPM2 therefore we made it available. We could add a big glaring
warning that SHA1 is broken and should not be used unless you have a
very specific reason.