Re: shim 16 breaking systemd stub and next steps

[Luca Boccassi <luca.boccassi@xxxxxxxxx>]

On Fri, 21 Mar 2025 at 14:37, Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
>
> On Do, 20.03.25 22:36, Luca Boccassi (luca.boccassi@xxxxxxxxx) wrote:
>
> > > > so I think your suggestion of adding a new API to shim is the best
> > > > solution. Once a formal API is established, we remove the chances of
> > > > accidental/unaware breakages going forward, which would be a very
> > > > positive outcome.
> > > >
> > > > And I share your sentiments w.r.t adding yet another NIH
> > > > reimplementation. It would be really strange if the addition of a
> > > > protocol results in grub shedding code and removing a local
> > > > reimplementation and using a common protocol instead, and sd-boot
> > > > doing the exact opposite...
> > >
> > > I disagree. Grub and sd-boot have fundamentally different goals. Grub
> > > wants to load arbitrary code and needs to ask the system to validate it.
> > > So it really wants to go through as many authentication and validation
> > > dances as possible: It effectively wants the LoadImage() call, just that
> > > because the world with shim is so messed up that it can't actually use it.
> >
> > We want to use the protocols to avoid having to maintain yet another
> > implementation of the same thing. What matters for distributions is
> > minimizing the amount of duplication, so that you don't have to
> > maintain multiple copies of the same thing, that get the same hardware
> > bugs to work around, the same security vulnerabilities, and the same
> > issues in general, multiple times.
> > For historic reasons, grub is what always had the greatest amount of
> > duplication - cryptography, encryption, filesystems, drivers, fonts,
> > you name it and it's got it. sd-boot's philosophy was the opposite,
> > don't be a boot loader, don't be a loader, just be a dumb menu
> > displayer, and let uefi handle the nitty-gritty. This has worked well
> > for us so far.
> >
> > The shim maintainers have expressed interest in providing a protocol
> > that allows us to correctly configure loadimage so that it doesn't
> > check the signature and it doesn't measure, which is what we need.
> > I'll provide further updates once there is something more concrete.
>
> Sorry, I think we should reduce the reliance on shim for stuff we
> really don't need it for, not increase it.
>
> I *really* don't get why we should talk to shim if we want *no*
> *validation* *at* *all*. What is shim supposed to be? I though it was
> about authenticating PE resources? But now you want us to call it even
> if we explicitly don't want authentication of PE resources? Seems
> totally backwards to me?

Aside from what was already mentioned, there are also a few more
advantages. I know you don't care about these use cases and that's
perfectly fine, but distributions and others do: by having a protocol
that lets shim validate the embedded image, you can ensure it checks
the hash of the kernel itself against dbx/mokx, and the sbat entry of
the kernel itself for revocations. So for example if a kernel is known
bad, it is possible to revoke its individual hash, and any number of
UKIs from any number of origins embedding it will still comply with
the revocation.