Adventures with the UEFI shim

[Paul Moore]

On Sun, Nov 15, 2020 at 1:05 PM James Bottomley
<James.Bottomley at hansenpartnership.com> wrote:
> 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.

I'm not convinced the "why" really matters here, but whatever makes
you happy James.  Sadly I think we can all point out several topic
areas where the published spec is lacking in some way and the
implementations vary as a result.

I was simply pointing out that I had already considered the problem
you mentioned regarding LoadOptions and had already proposed an
iterative fix that resolved the problem on my platform, and likely
improved the situation for others as well.

> 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.

At this point in time it seems that recommending users rely on a
secondary bootloader is a greater security risk than an incremental
fix for the LoadOptions handling, yet that's where we are at.  Of
course one could implement some other way to pass secondary loader
information to shim, a dedicated UEFI variable is an obvious choice,
but it seems like we are wandering rather far from the original
thread.

Do you see any reason why the PCR extensions I'm proposing as build
time options are a bad idea and not something that should be merged
into shim?

Do you see any reason why we need to keep the existing
ExitBootServices check as discussed above?  If yes, are you okay with
allowing the ExitBootServices check to be disabled via a build time
option?

-- 
paul moore
www.paul-moore.com