From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Eric Biggers <ebiggers@kernel.org>,
Ross Philipson <ross.philipson@oracle.com>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org,
linux-crypto@vger.kernel.org, iommu@lists.linux-foundation.org,
kexec@lists.infradead.org, linux-efi@vger.kernel.org,
dpsmith@apertussolutions.com, tglx@linutronix.de,
mingo@redhat.com, bp@alien8.de, hpa@zytor.com, ardb@kernel.org,
mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
luto@amacapital.net, nivedita@alum.mit.edu,
kanth.ghatraju@oracle.com, trenchboot-devel@googlegroups.com
Subject: Re: [PATCH v7 06/13] x86: Add early SHA support for Secure Launch early measurements
Date: Sat, 11 Nov 2023 18:19:12 +0000 [thread overview]
Message-ID: <a16d44c5-2e1a-4e9a-8ca1-c7ca564f61cd@citrix.com> (raw)
In-Reply-To: <20231111174435.GA998@sol.localdomain>
On 11/11/2023 5:44 pm, Eric Biggers wrote:
> On Fri, Nov 10, 2023 at 05:27:44PM -0500, Ross Philipson wrote:
>> arch/x86/boot/compressed/early_sha1.c | 12 ++++
>> lib/crypto/sha1.c | 81 +++++++++++++++++++++++++
> It's surprising to still see this new use of SHA-1 after so many people objected
> to it in the v6 patchset. It's also frustrating that the SHA-1 support is still
> being obfuscated by being combined in one patch with SHA-2 support, perhaps in
> an attempt to conflate the two algorithms and avoid having to give a rationale
> for the inclusion of SHA-1. Finally, new functions should not be added to
> lib/crypto/sha1.c unless those functions have multiple users.
The rational was given. Let me reiterate it.
There are real TPMs in the world that can't use SHA-2. The use of SHA-1
is necessary to support DRTM on such systems, and there are real users
of such configurations.
DRTM with SHA-1-only is a damnsight better than no DTRM, even if SHA-1
is getting a little long in the tooth.
So unless you have a credible plan to upgrade every non-SHA-2 TPM in the
world, you are deliberately breaking part of the usecase paying for the
effort of trying to upstream DRTM support into Linux.
~Andrew
next prev parent reply other threads:[~2023-11-11 18:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 22:27 [PATCH v7 00/13] x86: Trenchboot secure dynamic launch Linux kernel support Ross Philipson
2023-11-10 22:27 ` [PATCH v7 01/13] x86/boot: Place kernel_info at a fixed offset Ross Philipson
2023-11-10 22:27 ` [PATCH v7 02/13] Documentation/x86: Secure Launch kernel documentation Ross Philipson
2023-11-12 18:07 ` Alyssa Ross
2023-11-16 17:55 ` ross.philipson
2024-01-31 19:40 ` Daniel P. Smith
2023-11-10 22:27 ` [PATCH v7 03/13] x86: Secure Launch Kconfig Ross Philipson
2023-11-10 22:27 ` [PATCH v7 04/13] x86: Secure Launch Resource Table header file Ross Philipson
2023-11-10 22:27 ` [PATCH v7 05/13] x86: Secure Launch main " Ross Philipson
2023-11-10 22:27 ` [PATCH v7 06/13] x86: Add early SHA support for Secure Launch early measurements Ross Philipson
2023-11-11 17:44 ` Eric Biggers
2023-11-11 18:19 ` Andrew Cooper [this message]
2023-11-11 20:36 ` James Bottomley
2023-11-13 23:21 ` Andrew Cooper
2023-11-10 22:27 ` [PATCH v7 07/13] x86: Secure Launch kernel early boot stub Ross Philipson
2023-11-10 22:27 ` [PATCH v7 08/13] x86: Secure Launch kernel late " Ross Philipson
2023-11-10 22:27 ` [PATCH v7 09/13] x86: Secure Launch SMP bringup support Ross Philipson
2023-11-11 10:41 ` kernel test robot
2023-11-10 22:27 ` [PATCH v7 10/13] kexec: Secure Launch kexec SEXIT support Ross Philipson
2023-11-10 23:41 ` Sean Christopherson
2023-11-16 0:50 ` ross.philipson
2023-11-10 22:27 ` [PATCH v7 11/13] reboot: Secure Launch SEXIT support on reboot paths Ross Philipson
2023-11-10 22:27 ` [PATCH v7 12/13] x86: Secure Launch late initcall platform module Ross Philipson
2023-11-10 22:27 ` [PATCH v7 13/13] tpm: Allow locality 2 to be set when initializing the TPM for Secure Launch Ross Philipson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a16d44c5-2e1a-4e9a-8ca1-c7ca564f61cd@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=bp@alien8.de \
--cc=dpsmith@apertussolutions.com \
--cc=ebiggers@kernel.org \
--cc=hpa@zytor.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kanth.ghatraju@oracle.com \
--cc=kexec@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mingo@redhat.com \
--cc=mjg59@srcf.ucam.org \
--cc=nivedita@alum.mit.edu \
--cc=ross.philipson@oracle.com \
--cc=tglx@linutronix.de \
--cc=trenchboot-devel@googlegroups.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox