On Fri, Feb 23, 2024, at 10:30 AM, Eric Biggers wrote: > On Fri, Feb 23, 2024 at 06:20:27PM +0000, Andrew Cooper wrote: >> On 23/02/2024 5:54 pm, Eric Biggers wrote: >> > On Fri, Feb 23, 2024 at 04:42:11PM +0000, Andrew Cooper wrote: >> >> Yes, and I agree. We're not looking to try and force this in with >> >> underhand tactics. >> >> >> >> But a blind "nack to any SHA-1" is similarly damaging in the opposite >> >> direction. >> >> >> > Well, reviewers have said they'd prefer that SHA-1 not be included and >> > given >> > some thoughtful reasons for that. But also they've given suggestions on >> > how to >> > make the SHA-1 support more palatable, such as splitting it into a separate >> > patch and giving it a proper justification. >> > >> > All suggestions have been ignored. >> >> The public record demonstrates otherwise. >> >> But are you saying that you'd be happy if the commit message read >> something more like: >> >> ---8<--- >> For better or worse, Secure Launch needs SHA-1 and SHA-256. >> >> The choice of hashes used lie with the platform firmware, not with >> software, and is often outside of the users control. >> >> Even if we'd prefer to use SHA-256-only, if firmware elected to start us >> with the SHA-1 and SHA-256 backs active, we still need SHA-1 to parse >> the TPM event log thus far, and deliberately cap the SHA-1 PCRs in order >> to safely use SHA-256 for everything else. >> --- > > Please take some time to read through the comments that reviewers have left on > previous versions of the patchset.
So I went and read through the old comments, and I'm lost. In brief summary: If the hardware+firmware only supports SHA-1, then some reviewers would prefer Linux not to support DRTM. I personally think this is a bit silly, but it's not entirely unreasonable. Maybe it should be a config option? If the hardware+firmware does support SHA-256, then it sounds (to me, reading this -- I haven't dug into the right spec pages) that, for optimal security, something still needs to effectively turn SHA-1 *off* at runtime by capping the event log properly. And that requires computing a SHA-1 hash. And, to be clear, (a) this is only on systems that already support SHA-256 and that we should support and (b) *not* doing so leaves us potentially more vulnerable to SHA-1 attacks than doing so. And no SHA-256-supporting tooling will actually be compromised by a SHA-1 compromise if we cap the event log. So is there a way forward? Just saying "read through the comments" seems like a dead end. Thanks, Andy
