Adventures with the UEFI shim

[Paul Moore]

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

I also posted a couple of other PRs with unrelated fixes and build improvements.

-- 
paul moore
www.paul-moore.com