On 22/02/2024 9:34 am, Ard Biesheuvel wrote:
> On Thu, 22 Feb 2024 at 04:05, Andrew Cooper <andrew.cooper3@xxxxxxxxxx> wrote:
>> On 15/02/2024 8:17 am, Ard Biesheuvel wrote:
>>> On Wed, 14 Feb 2024 at 23:31, Ross Philipson <ross.philipson@xxxxxxxxxx> wrote:
>>>> From: "Daniel P. Smith" <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>>>
>>>> The SHA algorithms are necessary to measure configuration information into
>>>> the TPM as early as possible before using the values. This implementation
>>>> uses the established approach of #including the SHA libraries directly in
>>>> the code since the compressed kernel is not uncompressed at this point.
>>>>
>>>> The SHA code here has its origins in the code from the main kernel:
>>>>
>>>> commit c4d5b9ffa31f ("crypto: sha1 - implement base layer for SHA-1")
>>>>
>>>> A modified version of this code was introduced to the lib/crypto/sha1.c
>>>> to bring it in line with the sha256 code and allow it to be pulled into the
>>>> setup kernel in the same manner as sha256 is.
>>>>
>>>> Signed-off-by: Daniel P. Smith <dpsmith@xxxxxxxxxxxxxxxxxxxx>
>>>> Signed-off-by: Ross Philipson <ross.philipson@xxxxxxxxxx>
>>> We have had some discussions about this, and you really need to
>>> capture the justification in the commit log for introducing new code
>>> that implements an obsolete and broken hashing algorithm.
>>>
>>> SHA-1 is broken and should no longer be used for anything. Introducing
>>> new support for a highly complex boot security feature, and then
>>> relying on SHA-1 in the implementation makes this whole effort seem
>>> almost futile, *unless* you provide some rock solid reasons here why
>>> this is still safe.
>>>
>>> If the upshot would be that some people are stuck with SHA-1 so they
>>> won't be able to use this feature, then I'm not convinced we should
>>> obsess over that.
>> To be absolutely crystal clear here.
>>
>> The choice of hash algorithm(s) are determined by the OEM and the
>> platform, not by Linux.
>>
>> Failing to (at least) cap a PCR in a bank which the OEM/platform left
>> active is a security vulnerability. It permits the unsealing of secrets
>> if an attacker can replay a good set of measurements into an unused bank.
>>
>> The only way to get rid of the requirement for SHA-1 here is to lobby
>> the IHVs/OEMs, or perhaps the TCG, to produce/spec a platform where the
>> SHA-1 banks can be disabled. There are no known such platforms in the
>> market today, to the best of our knowledge.
>>
> OK, so mainline Linux does not support secure launch at all today. At
> this point, we need to decide whether or not tomorrow's mainline Linux
> will support secure launch with SHA1 or without, right?
I'd argue that's a slightly unfair characterisation.
We want tomorrow's mainline to support Secure Launch. What that entails
under the hood is largely outside of the control of the end user.
> And the point you are making here is that we need SHA-1 not only to a)
> support systems that are on TPM 1.2 and support nothing else, but also
> to b) ensure that crypto agile TPM 2.0 with both SHA-1 and SHA-256
> enabled can be supported in a safe manner, which would involve
> measuring some terminating event into the SHA-1 PCRs to ensure they
> are not left in a dangling state that might allow an adversary to
> trick the TPM into unsealing a secret that it shouldn't.
Yes. Also c) because if the end user wants to use SHA-1, they should be
able to.
> So can we support b) without a), and if so, does measuring an
> arbitrary dummy event into a PCR that is only meant to keep sealed
> forever really require a SHA-1 implementation, or could we just use an
> arbitrary (not even random) sequence of 160 bits and use that instead?
a) and b) are in principle independent, but we cannot support b) without
SHA-1.
To cap a PCR, the event log still needs to be kept accurate, and that's
at least one SHA-1 calculation. If you were to simply extend a dummy
value, the system hopefully fails safe, but the user gets "something
went wrong, you're on your own", rather than "we intentionally blocked
the use of SHA-1, everything is good".
And frankly, you need SHA-1 just to read the event log, if any component
(including TXT itself) wrote a SHA-1 entry into it.
To be blunt. SHA-1 support is not viably optional today as far as
Secure Launch is concerned. If there's a suitable Kconfig symbol to use
for people who want a completely SHA-1-less kernel, then we can make
Secure Launch depend on that until such time as the hardware ecosystem
has caught up.
~Andrew
