[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] tpm: Don't propagate measurement failures to the verifiers l
From: |
Javier Martinez Canillas |
Subject: |
Re: [PATCH] tpm: Don't propagate measurement failures to the verifiers layer |
Date: |
Wed, 3 Mar 2021 18:53:48 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 |
Hello Daniel,
On 3/3/21 6:28 PM, Daniel Kiper wrote:
> On Sun, Feb 28, 2021 at 03:25:04PM -0800, James Bottomley wrote:
>
> [...]
>
>> How about a more simple solution: you sign two grub unitary EFI
>> binaries, one of which does measured boot and one of which doesn't.
>> Your installer is already config file driven, so by default it would
>> install the measured boot one, but if there's a failure you can tell
>> the user to add the config option to install the unmeasured boot one
>> ... this could also be useful for various other situations where you
>> want secure but not measured boot? I'm fairly certain you could design
>> a distro installer test for the problem and thus always install a
>> working system. There's no security issue because anyone who does
>> attested measured boot will instantly detect someone booting via the
>> signed unmeasured boot grub.
>>
>> Note: I'm certainly not presenting this as the optimal solution, merely
>> the least effort solution that looks like it will work with the current
>> grub upstream.
>
> I think we can do this in much simpler way. Let's use one GRUB Secure
> Boot signed image which contains the tpm module embedded. By default the
> tpm verifier will ignore UEFI errors and always return GRUB_ERR_NONE.
> However, if somebody cares about these errors they can set, e.g.,
> tpm_err_ignore environment variable in grub.cfg to false. Then if the
> TPM UEFI calls fail for any reason machine boot fails. Does it work for
> you guys?
>
That sounds sensible to me. As long as the default is to ignore errors
as you suggested (i.e: leading to an unbootable system is opt-in and not
opt-out), I agree with the approach and can prepare a v2 that does this.
> Daniel
>
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat