Adventures with the UEFI shim

[Peter Jones]

On Thu, Oct 01, 2020 at 03:16:08PM -0400, Paul Moore wrote:
> Hello all,
> 
> I was looking for a list to discuss the UEFI shim and was directed
> here, if there is a better place please correct me.

This is the place, but we've only just set the list up, so there's not
much here yet.

> While most shim use cases involve using shim to load GRUB which in
> turn loads the kernel/OS, I'm looking to use shim to boot the
> kernel/OS directly.  Specifically, I want to use shim to boot a
> combined kernel+initrd+cmdline EFI application using the systemd-boot
> EFI stub.  Unfortunately I've been running into problems with shim's
> ExitBootServices hook.  Looking at the code, it would appear that shim
> expects (and requires) that some piece of the bootloader chain calls
> into shim's verification protocol to authorize the kernel prior to
> calling ExitBootServices.  This would normally be handled by GRUB, or
> any other bootloader in the chain, but if there is no bootloader
> beyond shim things fall apart.
>
> If this was anything but shim, the fix would be a small and
> straightforward patch to replacements.c:exit_boot_services() but since
> our project would eventually like to get a shim signed by Microsoft we
> need to find a solution that is suitable for the rhboot/shim-review
> crowd.

Let me start by saying that I don't think there's a good answer here,
for a lot of reasons.  The biggest one is that systemd-boot is LGPL and
linux is GPL licensed, and Microsoft has stated repeatedly that they're
not going to sign images that are GPL licensed.  That's a part of why
shim exists in the first place.

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 the shim lock protocol on the embedded kernel

But that's clearly not going to work because of the licensing of the
resulting packed binary.

So I guess the questions are:

- What's your reasoning for wanting to go the systemd-boot packed
  binary route?  There may be more options, depending on which parts of
  that design are critical to you.
- If you can share, what does your timeline for needing something signed
  look like?

> I've got a couple of ideas on ways this could be resolved, but
> I wanted to check with the list to see if anyone has attempted this
> before, and if so, how they did it.  I can't believe I'm the first to
> attempt this.

I don't think anyone has actually tried to do this in a way that honors
the Secure Boot threat model.

> As an aside, how do people do dev/test of the UEFI shim when UEFI
> Secure Boot is enabled?  I originally thought I could use a Microsoft
> signed shim to boot my development shim which would finally boot the
> kernel/OS, but I'm running afoul of the nested EFI service hooks.  Any
> advice you can provide would be appreciated.

We use Qemu with OVMF (see the "edk2" packages in fedora for example
builds) and enroll our own certs and self-sign everything.  The biggest
"gotcha" there is to be sure you have one cert that's in 'db' and signs
shim, and a completely different cert that shim trusts, which signs
anything shim might be loading.  That said, my statement here is
obviously not written with your attempt to use systemd-boot in mind.

-- 
        Peter