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

[Ard Biesheuvel]

On Tue, 24 Feb 2026, at 00:08, Andrew Cooper wrote:
> 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.
>

That was my question, yes. So supporting TPM 1.2 as well as TPM 2.0 with only SHA-1 banks enabled is needed not to comply with the spec, but to support existing out-of-tree users. That needs to be called out, because what I am quoting above is a claim that it is needed to comply with the TXT MLE spec.

So the debate is really about whether or not such systems should be considered obsolete at this point.

And why is it ok to just cap active SHA-384 banks rather than perform the proper measurements?

> 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.
>

3-year old hardware that shipped with a TPM 1.2?

> 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 complexity of the code is not the problem. The problem is that we'll be stuck supporting it long past the point where anyone is making meaningful use of it. I'm not keen on being on the receiving end of a bug report from your last remaining TPM 1.2 user, with no means whatsoever to test or reproduce.

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

Sure, some systems will be left behind. I just wonder how many of those would be upgrading to the v7.3 LTS kernel to begin with, 4 years after TPM 1.2 support was dropped from the TXT spec.

In any case, the code changes themselves look fine to me. I am more concerned about the long term maintenance: the x86 boot code is very complex, given how many boot methods it supports, and it is rather difficult to regression test all of those.