Re: shim 16 breaking systemd stub and next steps

[Luca Boccassi <luca.boccassi@xxxxxxxxx>]

On Fri, 21 Mar 2025 at 08:05, Alexander Graf <graf@xxxxxxxxxx> wrote:
>
>
> On 21.03.25 01:26, Luca Boccassi wrote:
> > On Thu, 20 Mar 2025 at 22:43, Alexander Graf <graf@xxxxxxxxxx> wrote:
> >> Let's first figure out how all of this works without shim. Then we can
> >> look at whether we need to and how we can extend the shim/sd-boot
> >> interface to make that case work as well. Please don't start off
> >> assuming everyone runs shim in secure boot environments.
> > But that's a bit off topic, though - the issue Mate brought up with
> > this thread is specifically with shim/16 + sd-boot + sd-stub, which is
> > a bit time pressing as both Plucky and Trixie are about to go out with
> > this combination that used to work, but doesn't anymore.
> > Without shim there's no new issue, everything works as it always did.
>
>
> If you read through Heinrich's reply once more, you can clearly see that
> it does not. We have 2 broken cases: new shim (change of contract) and
> U-Boot (dependency on PI internals).

Sorry, but "not standard compliant" is really not an interesting
argument per se. systemd is not posix standard compliant either, we
use glibc specific APIs when they are useful and make sense to avoid
reinventing things that the libc should really be in charge of
maintaining. Other libcs can either implement the same interfaces, or
folks interested in using them can provide and maintain compat shims.
That's always been the rule around here.
This really looks the same to me, EDK2 provides these APIs that are
from the PI spec rather than the main one, and if they are available,
we use them, because they are useful. We also already use other
shim-provided protocols, that are also not from the UEFI spec. In fact
we are a bit nicer than in userspace, as these are used only if
available, there's no hard failure if not.
Then if one day these protocols (or similar alternatives) make their
way into the main spec, all the better of course, that would be great.

If U-Boot doesn't provide the same interfaces that EDK2 has, and they
can't be added, then double signing should work I think, IIRC we got
reports that it was enough to run things on U-Boot in the past.