Adventures with the UEFI shim

[Paul Moore]

On Sat, Nov 14, 2020 at 12:24 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> On Sat, 2020-11-14 at 11:58 -0500, Paul Moore wrote:
> > 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:
> [...]
> > > > 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
>
> The UEFI boot manager can pass the OptionalData from the LoadOption to
> the next binary and shim will try to process this to extract the next
> stage loader, but the process is somewhat fragile if you read the
> polemic inside shim on all the problems:
>
> https://github.com/rhboot/shim/blob/15.2/shim.c#L2340-L2530

I've previously submitted a PR, that oddly enough starts with that
exact polemic, to address the LoadOptions problems I've seen.  It has
been tested both on physical hardware as well as QEMU+OVMF.

* https://github.com/rhboot/shim/pull/226

> Are you sure you don't want do do it the selector way, which would be
> reliable on all platforms?

Yup.  I'm sure one of the things I want to do is minimize the amount
of code that runs between UEFI and the kernel/OS.

-- 
paul moore
www.paul-moore.com