Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch early measurements

["Ard Biesheuvel" <ardb@kernel.org>]

Coming back to this old thread after having spent some time playing with the code:

On Thu, 22 Aug 2024, at 20:29, Daniel P. Smith wrote:

<selective snip>

> Another fact to consider is that the current Intel's TXT MLE 
> specification dictates SHA1 as a valid configuration. Secure Launch's 
> use of SHA1 is therefore to comply with Intel's specification for TXT. 

As I understand the Intel TXT spec and the code:

- TPM 1.2 is no longer supported by the TXT spec (since 2023)
- TPM 1.2 is not supported by your GRUB implementation
- in TPM 2.0 mode, SHA1 is only supported by the TXT spec if it is the /only/ algo supported by the TPM
- the proposed kernel implementation ignores any SHA-384 and SM3-256 PCR banks if they are active, and caps them using a { 1, 0, ... } fake digest.

So apologies for being slow, but I still struggle to understand why it is so important to have a SHA-1 implementation to cap those PCRs. Is it just to support systems with a TPM 2.0 that only has SHA-1 banks enabled?

Assuming that this code will get merged this year, it will be in a LTS branch by 2027, by which time distros like Debian will pick it up. 

I fully understand that this code has lived out-of-tree for more than a decade, and you likely prefer to get everything upstream that your current users may be relying on. But for Linux, this is a new feature, and merging code now that is basically obsolete on day 1 is not something we should entertain imo.

(and apologies for re-opening yet another can of worms - I assure you I am trying to be constructive here)

-- 
Ard.