Adventures with the UEFI shim

[Paul Moore]

On Fri, Nov 13, 2020 at 12:00 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Fri, 2020-11-13 at 17:24 +0100, Javier Martinez Canillas wrote:
> > [adding more people that I think will have a say on this topic]
>
> Thanks for that.  I hadn't realised this list was still active.  I
> looked in the archives and this:
>
> > 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.
>
> Way back when the first secure boot systems were being worked on,
> gummiboot (the systemd-boot precursor) was on the list of things to
> support.  The support proposal I pioneered then was to hook into the
> architecture security protocol to allow the shim to hook into the
> standard platform verifier which means it works with LoadImage that
> systemd-boot uses.  I think it's gated on the environment variable
> OVERRIDE_SECURITY_POLICY in shim.  If you set this, does everything now
> work as you expect?
>
> If it does, it looks like shim may need an update, because the
> security_policy.c has become a bit more sophisticated since lib was
> forked in 2012:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git/tree/lib/security_policy.c

It turns out there is some code in systemd-boot to do verification via
the shim protocols, but in my particular case I want to verify the
signature on the entire kernel+initrd+cmdline EFI binary not just the
kernel section.  The idea being that we can use the UEFI SB iterative
signature based approach to authorize not just the kernel, but the
initrd and cmdline as well.  If I smash the kernel+initrd+cmdline
together into a single binary, I can sign the result and all is well.

Somewhat related: I grew tired of building all of systemd to get the
EFI stub and worrying about all that extra code in the stub so I
forked/extracted systemd-boot and put it on a diet, the result is in
the repo below:

* https://github.com/atomixos/stubby

-- 
paul moore
www.paul-moore.com