Re: shim 16 breaking systemd stub and next steps

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

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?

it's fine if shim and sd-stub is used together, but the coupling
should be as loose as possible, since it's not clear at all to me that
shim should be part of clean boot stack.

I understand you have some attachment to shim. I don't understand
why. But let's not let that leak into our codebase.

Lennart

--
Lennart Poettering, Berlin