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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9c80e779b6268fde33c93ed3765ff93b1d6d007b.camel@HansenPartnership.com>
Date: Mon, 18 Nov 2024 14:12:51 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Andy Lutomirski <luto@...capital.net>, "Daniel P. Smith"
	 <dpsmith@...rtussolutions.com>
Cc: Thomas Gleixner <tglx@...utronix.de>, "Eric W. Biederman"
 <ebiederm@...ssion.com>, Eric Biggers <ebiggers@...nel.org>, Ross Philipson
 <ross.philipson@...cle.com>, linux-kernel@...r.kernel.org, x86@...nel.org, 
 linux-integrity@...r.kernel.org, linux-doc@...r.kernel.org, 
 linux-crypto@...r.kernel.org, kexec@...ts.infradead.org, 
 linux-efi@...r.kernel.org, iommu@...ts.linux-foundation.org,
 mingo@...hat.com,  bp@...en8.de, hpa@...or.com,
 dave.hansen@...ux.intel.com, ardb@...nel.org,  mjg59@...f.ucam.org,
 peterhuewe@....de, jarkko@...nel.org, jgg@...pe.ca,  nivedita@...m.mit.edu,
 herbert@...dor.apana.org.au, davem@...emloft.net,  corbet@....net,
 dwmw2@...radead.org, baolu.lu@...ux.intel.com,  kanth.ghatraju@...cle.com,
 andrew.cooper3@...rix.com,  trenchboot-devel@...glegroups.com
Subject: Re: [PATCH v9 06/19] x86: Add early SHA-1 support for Secure Launch
 early measurements

On Mon, 2024-11-18 at 10:43 -0800, Andy Lutomirski wrote:
> Linux should not use TPM2_PCR_Extend *at all*.  Instead, Linux should
> exclusively use TPM2_PCR_Event.  I would expect that passing, say,
> the entire kernel image to TPM2_PCR_Event would be a big mistake, so
> instead Linux should hash the relevant data with a reasonable
> suggestion of hashes (which includes, mandatorily, SHA-384 and *does
> not* include SHA-1, and may or may not be configurable at build time
> to include things like SM3), concatenate them, and pass that to
> TPM2_PCR_Event.  And Linux should make the value that it passed to
> TPM2_PCR_Event readily accessible to software using it, and should
> also include some straightforward tooling to calculate it from a
> given input so that software that wants to figure out what value to
> expect in a PCR can easily do so.

Just for clarity, this is about how the agile log format works.  Each
event entry in the log contains a list of bank hashes and the extends
occur in log event order, so replaying a log should get you to exactly
the head PCR value of each bank.  If a log doesn't understand a format,
like SM3, then an entry for it doesn't appear in the log and a replay
says nothing about the PCR value.

For some events, the hash is actually the hash of the event entry
itself and for others, the entry is just a hint and the hash is of
something else.

I think part of the confusion stems from the twofold issues of PCRs: at
their simplest they were expected to provide the end policy values
(this turns out to be problematic because there are quite a few ways,
that will produce different end PCR values, that a system could get to
the same state).  If you don't trust a bank (or don't know about it),
you don't code it into a required policy statement and its value
becomes irrelevant.  If, as most remote attestation systems do, you're
analysing log entries, then you can calculate end PCR points for all
banks mentioned in the log and you could ask the TPM to quote all of
them.  In practice, you tend to pick a bank you prefer (sha256 usually)
and quote only that.  Again, if a bank doesn't appear in the log,
you're not going to ask for a quote from it, so what it contains is
irrelevant to the analysis of the log.

The point being that in neither case would the fact that boot software
failed to extend a bank it didn't have a hash for result in some type
of compromise.

Note that one of the things you can do with the log (because the
entries are separable) is strip out all the hashes for a bank. 
However, the remote is likely to refuse to accept the log if you, say,
strip the sha256 ones because you think a collision allows you to fake
a sha1 log because it would know you should have had sha256 entries as
well.

By the way, the only modern hash you can rely on a TPM2 having is
sha256.  Most of the older ones don't have sha384.  They all do have
sha1 for backwards compatibility with TPM1.2

James