[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b3e7003e-9019-5402-0205-0248a4c24584@apertussolutions.com>
Date: Thu, 26 Mar 2020 18:49:49 -0400
From: "Daniel P. Smith" <dpsmith@...rtussolutions.com>
To: Andy Lutomirski <luto@...nel.org>,
Ross Philipson <ross.philipson@...cle.com>
Cc: LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
"open list:DOCUMENTATION" <linux-doc@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, trenchboot-devel@...glegroups.com
Subject: Re: [RFC PATCH 03/12] x86: Add early SHA support for Secure Launch
early measurements
On 3/25/20 11:44 PM, Andy Lutomirski wrote:
> On Wed, Mar 25, 2020 at 12:43 PM Ross Philipson
> <ross.philipson@...cle.com> 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 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@...rtussolutions.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.
Powered by blists - more mailing lists