Adventures with the UEFI shim

[Paul Moore]

On Sat, Nov 14, 2020 at 11:52 AM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Fri, 2020-11-13 at 12:09 -0500, Paul Moore wrote:
> > 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
>
> OK, so I understand what stubby is and what it does and why there's an
> exit boot services issue with shim->stubby-smash however, I have to ask
> why you think this is an important use case?  Even systems that use
> stubby are going to need to upgrade kernels and fallback if there's an
> upgrade problem, so they're going to need some form of boot selection
> still.  That means the field use case would most likely be:
>
> shim->selector->stubby-smash

Our use case involves leveraging the built-in UEFI boot manager and
specifying the kernel via LoadOptions to shim.  It allows us to offer
active/fallback/etc. kernels without the need for a "selector" or
second-stage loader.  It looks more like this:

  UEFI_bootmgr->shim->stubby/kernel

-- 
paul moore
www.paul-moore.com