[systemd-devel] Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Lennart Poettering]

On Mi, 27.04.22 18:57, Michael Biebl (mbiebl at gmail.com) wrote:

> >From https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996202#60
>
> """
> we have recently discussed the matter of systemd-boot in
> an upstream shim review gathering.

Ominous.

> We reject a signing of systemd-boot as
>
> * systemd-boot does not use current ways of communicating with
>   shim

It does not? What does that even mean, and why does that even matter?

Also, it does communicate with shim, see src/boot/efi/shim.c… And
there's SBAT support, which is a shim thing afaik.

> * There was some concern over general quality

Humpf. That's just 1st rate FUD. I mean, if systemd for PID 1 is OK'ed
by distros, then maybe the boot loader maintained by the same people
should be fine too. i'd be curious what precisely the "quality" issues
are supposed to be…

> * systemd-boot is an additional bootloader, rather than replacing
>   an existing one, thus increasing the attack surface.

Hmm, what? "additional bootloader"? Are they suggesting you use grub
to start sd-boot? I mean, you certainly could do that, but the only
people I know who do that do that to patch around the gatekeeping that
the shim people are doing. Technically the boot chain should either be
[firmware → sd-boot → kernel] or [firmware → shim → sd-boot → kernel]
(if you buy into the shim thing), and nothing else.

>   If people want to experiment with other bootloaders than the
>   default one, they can disable secure boot, or load their own
>   keys into the machine. We do not consider it valid to have
>   a choice of bootloaders.
>
> I want to note that the current shim has been signed with the
> understanding that it will trust grub, kernels, and fwupd. A
> signing of systemd-boot might be considered reasons for revoking
> the existing shim, and will certainly result in new shims not
> getting signed.

Christ! That's some gatekeeping.

Lennart

--
Lennart Poettering, Berlin