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

[Andrew Cooper]

On 20/02/2026 3:35 pm, Ard Biesheuvel wrote:
> 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)
>

I appreciate that you've got concerns, but I don't think these
characterisations are fair.  Ultimately yes, we do want to support TPM
1.2 systems because we have users wanting a way off the out-of-tree patches.

3-year-old hardware is new enough to still be in full support from OEMs,
and totally fair game for distro LTS's even at this juncture.

The TXT spec does not speak for what OEMs choose to support, nor for the
TPM spec (where SHA1 is a mandatory algorithm for TPM 2.0), nor does it
speak for other silicon vendors we're trying to support (there are AMD
patches waiting for the interface to stop changing).


But lets ask the question the other way around.  What does refusing SHA1
gain?

AFAICT, there's no meaningful reduction in complexity in the early code;
the TPM library speaks TPM 1.2 and 2.0.  There is a small reduction in
binary size for not including SHA-1, but including it is no extra C
because we reuse the library that already exists.

The cost is a failure to operate in some TXT configurations that exist
on in-support CPUs, as well as older systems.

~Andrew