Adventures with the UEFI shim

[James Bottomley]

On Sat, 2020-11-14 at 17:01 -0500, Paul Moore wrote:
> 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.

The mess in load options is driven by the unclarity of the UEFI
standard and the manufacturers won't add clarity (well not unless the
standard blesses what they've done, which is impossible given all the
differences) so we're stuck.  Surely it would satisfy your "less code"
desire if we simply eliminated the shim option handling and did our own
well defined selector mechanism.  Adding more code to handle more
special cases in load options is asking for security bugs.

James