Adventures with the UEFI shim

[James Bottomley]

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

And that selector could be a cut down version of systemd-boot, since
you already have the initrd and cmdline in the stubby-smash and don't
need it again.  If the selector goes via LoadImage/StartImage and you
have the security protocol override in place, then shim will just work
as is because the selector will satisfy the secondary loader check. 
This system should have the watertight security you want making the
kernel/initrd/cmdline combination, but also the flexibility to cope
with upgrade problems.

James