Re: shim 16 breaking systemd stub and next steps

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 21.03.25 11:06, Luca Boccassi (luca.boccassi@xxxxxxxxx) wrote:

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

It's not per se, but certainly the reality is that this current
hackery means we are not compatible with u-boot. So the standard
compliancy issue *is* hurting us. Which sucks, and we should fix.

And it's not that hard. Again, we already have a PE parser in place
(that's what systemd-stub after all *is*), we need to add a bit of
section relocation, and we should be done. Don't make this sound as if
this was an effort as complex as a file system driver or so, because
it *really* is not. It's just adding a bit more stuff to code we
*already* have in place that concerns itself with PE.

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

This is not comparable. The spec tells us explicitly not to do what we
are doing, and we do it anyway. And that has become a problem: we
break on one popular implementation of uefi: u-boot.

posix otoh doesn't tell us "do not use epoll" or so, it just tells you
at best "use epoll whatever, but it's not going to be portable most
likely". Which is a whole different category.

Anyway, I'd just beef up our PE logic a bit, to do the bit of
relocations needed, and then jump into the entrypoint. It's simple,
it's fast, it's safe, works on any uefi implementation, improves
compatibility, adds no new deps on some niche protocol that binds us
to shim (which, I am so very sure is something we should support for
compat only at best). In fact, I am much happier to just maintain that
bit of code ourselves than rely on shim for anything.

I mean if you have an issue with us parsing PE, then systemd-stub is
not suitable for you anyway, it's literally the one, the primary thing
it does.

Lennart

--
Lennart Poettering, Berlin