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
