Adventures with the UEFI shim

[Javier Martinez Canillas]

[adding more people that I think will have a say on this topic]

On 10/29/20 11:24 PM, Paul Moore wrote:
> On Sun, Oct 11, 2020 at 8:39 PM Paul Moore <paul at paul-moore.com> wrote:
>> On Sun, Oct 11, 2020 at 2:50 PM Peter Jones <pjones at redhat.com> wrote:
>>> On Thu, Oct 08, 2020 at 11:42:33AM -0400, Paul Moore wrote:
>>>> On Wed, Oct 7, 2020 at 3:17 PM Peter Jones <pjones at redhat.com> wrote:
>>>>> On Thu, Oct 01, 2020 at 03:16:08PM -0400, Paul Moore wrote:
> 
> ...
> 
>>>>> If it weren't for that, I would say:
>>>>> - put a pubkey in shim like normal
>>>>> - sign your kernel with it
>>>>> - make systemd-boot call thezi shim lock protocol on the embedded kernel
>>>>
>>>> Yes, I'm already planning on steps 1 and 2 (those are needed pretty
>>>> much regardless of the design), I was just wondering if the UEFI shim
>>>> folks would be open to working on solution that doesn't require the
>>>> "loader_is_participating" check in shim's ExitBootServices hook.
>>>> Conceptually if shim has already verified the signature on the next
>>>> stage of the boot process that would seem to imply a certain level of
>>>> trust in that binary.  Would you be open to a mechanism for post-shim
>>>> loaders to signal shim that they do not need additional verification
>>>> via the shim protocol?
>>>
>>> I think that sounds like a reasonable trade-off, yes, though I do think
>>> we'd want to see the code during review, just to be sure.
>>
>> That's fair.  Do you have any suggestions about how to skip the
>> "loader_is_participating" check that you would find acceptable
>> upstream?  As I said above, I think just removing it should be
>> reasonable and in keeping with the transitive trust of UEFI SB, but
>> I'm happy taking a different approach if that is what you guys want.
> 
> In an effort to move this discussion forward I posted my current code
> as a PR here:
> 
> * https://github.com/rhboot/shim/pull/233
> 

As far as I can tell you are trying to overcome the following limitations
that exist with the current PCR measurements in shim and GRUB:

1) PCR7 can suffer of PCR fragility because it measures the db and dbx
   variables and this could change due an EFI firmware update.

2) PCR9 only contains measurements of the kernel if GRUB is used.

I wonder if what is measured and the PCR extended could be changed in
shim and GRUB to have a more flexible policy that could solve both.

That is, maybe using a different PCR for db and dbx? That way PCR7
will have stable measurements across firmware updates, and if db/dbx
should be part of a PCR policy, then this other PCR could be used in
conjunction with PCR7.

Same question about PCR9, maybe the loader_is_participating variable
can be used to tell shim if should extend PCR9 with the loaded image?

Because a problem I see with your patches is that it seems to me that
are adding a bunch of build time options that could be mix and matched
to have ad-hoc TPM measurements policies.

We could add defaults for these, but I guess that will be confusing and
also the attestation services will need to be aware of what was enabled
or disabled in shim for a given setup.

A third thing that that your patches tackle is shim's assumption that
a second stage bootloader using the shim_lock protocol will be part of
the boot path.

I've to admit that I don't fully understand why the ExitBootServices()
is checking for the loader_is_participating variable, since it already
trusts the binary and could just assume that would do the right thing.

For example, what prevents a second stage bootloader to verify an image
but boot a different one? I see that there is a check in the hooked
StartImage() but the bootloader could still subvert this when using the
EFI handover protocol? Since in that case just jumps directly to the PE
entry point.

So if I understand correctly we could just remove the check in the hooked
ExitBootServices() for the loader_is_participating, if that prevents an
already trusted kernel to be booted directly from shim.

Best regards,
Javier