Adventures with the UEFI shim

[James Bottomley]

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

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

James