Re: shim 16 breaking systemd stub and next steps

[Luca Boccassi <luca.boccassi@xxxxxxxxx>]

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.

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