Re: shim 16 breaking systemd stub and next steps

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Do, 20.03.25 12:08, Luca Boccassi (luca.boccassi@xxxxxxxxx) wrote:

> On Thu, 20 Mar 2025 at 11:00, Mate Kukri <mate.kukri@xxxxxxxxxxxxx> wrote:
> >
> > Hello,
> >
> > A new version of the rhboot secure boot shim was released yesterday
> > https://github.com/rhboot/shim/releases/tag/16.0.
> >
> > This version contains an implementation of the
> > LoadImage/StartImage/Exit/etc API set, which is exposed both via
> > SystemTable hooks, and a new protocol called the shim loader protocol.
> > This allows second stage bootloaders to load and execute shim signed
> > PE binaries the same way as ones signed by firmware keys.
> >
> > Unfortunately this also means that systemd-stub will no longer be able
> > to load its embedded kernel due to relying on overriding the non-UEFI
> > standard SECURITY2_ARCH_PROTOCOL to avoid verification which the shim
> > LoadImage implementation of course does not consult.
> >
> > I really hope the solution to this won't be another copy pasted PE
> > loader inside the stub (as one of the big goals of the loader protocol
> > work was to avoid the multiplication of PE loaders...)
> > One possible solution is to add a new API to shim to allow loading
> > previously verified images such as the embedded kernel without further
> > verification.
> >
> > I am looking to hear your thoughts on how to fix this issue.
>
> Thanks for the heads-up - the reason we ended up in this situation is
> ultimately because we didn't coordinate with shim for this workaround,
> 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.

Strongly disagree. I find compat with u-boot a lot more interesting
than working around shim's whims by talking to even more specific shim
protocol.

If we add the bit of relocation to our already existing PE parser we
gain compat with both u-boot + new shim at the same time and can claim
standards compliance. Seems like a pretty obvious choice for me.

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

Urks. "NIH". Really? We have shipped a PE parser in sd-stub from day
one. It's pretty much what it does. If you think that's NIH and
terrible, then sd-stub isn't really an option for you.

Lennart

--
Lennart Poettering, Berlin