On Mon, Nov 18, 2024 at 10:43 AM Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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. Whoops, putting on my "knows a bit about crypto" hat for a second, this is not great, as the algorithms aren't distinguished, and one could hypothetically add a wildly insecure hash to the list that breaks it. Instead it should be something like: "SHA-384 48 bytes: [the SHA-384 data], someotherhash 71 bytes: [other data], ..." It might even be polite to include some human readable text that also indicates what got hashed, e.g. "initramfs", so that anyone reading the event log can see what got hashed. On that note, maybe making the whole thing human readable and using base64 would be nice: "initramfs\nsha384 [base64 data]\nblake3 [base64 data]\nsm3 [base64 data]" Whatever format is used should be unambiguously parseable. And who knows, maybe there's already some kind of industry standard for how TPM-using software is expected to behave here. > > And then software that wants to use a SHA-1 bank will work every bit > as well as it would if Linux actually implemented it, but Linux can > happily not implement it, and even users of oddball algorithms that > Linux has never heard of will get secure behavior. > > (Why SHA-384? Because it's mandatory in the TPM Client profile, and > anyone who's happy with SHA-256 should also be willing to accept > SHA-384.) > > > > > Even with these clarifications, the conclusion does not change. If the > > firmware enables SHA1, there is nothing that can be done to disable or > > block its usage from the user. Linux Secure Launch sending measurements > > to all the banks that the hardware used to start the DRTM chain does not > > create a vulnerability in and of itself. The user is free to leverage > > the SHA1 bank in any of the TPM's Integrity Collection suite of > > operations, regardless of what Secure Launch sends for the SHA1 hash. > > Whereas, neutering the solution of SHA1 breaks the ability for it to > > support any hardware that has a TPM1.2, of which there are still many in > > use. > > > > V/r, > > Daniel P. Smith > > > > > > > -- > Andy Lutomirski > AMA Capital Management, LLC -- Andy Lutomirski AMA Capital Management, LLC
