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.
