grub-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]