Re: Splitting sd-boot from systemd/bootctl for enabling sd-boot in Fedora

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 26.04.22 19:12, Neal Gompa (ngompa13@xxxxxxxxx) wrote:

> Hey all,
>
> Some of you might know about the recent discussion in Fedora about
> dropping BIOS support[1][2]. While the end result for now is that
> we're not dropping it[3], several side discussions involved enabling
> systemd-boot as an option in Fedora in the future.
>
> While I *personally* am not a huge fan of systemd-boot itself, I
> *am*

I asked this elsewhere already, without getting a reply: why aren't
you though? Can you elaborate on what crucial thing you are missing?

> * bootctl(1) appears to be tightly coupled to sd-boot

Well, kinda. But also not. So if you type "bootctl --help" then you'll
see three sections of commands. The last section "systemd-boot
Commands" shows commands that only really make sense for systemd-boot
as they install/remove/update the boot loader itself. They are the
only things inherently tied to sd-boot.

The other two sections are useful outside of sd-boot: the first
section ("Generic EFI Firmware/Boot Loader Commands") is useful on any
kind of UEFI section, the second section ("Boot Loader Specification
Commands") on all boot loaders that implement the (upstream) boot loader
spec/boot loader interface, as documented.

Note though that at this point grub does not implement either of the
specs properly, or has any upstream work in that area to my
knowledge.

> The first problem is mostly because I think bootctl(1) is a fantastic
> interface to manage *any* Bootloader Spec[4] (BLS) conformant boot
> manager, and I would love for that tool to be useful for doing so.
> Being able to do things like install/upgrade/swap GRUB 2,
> systemd-boot, or any other registered BLS-enabled boot manager would
> make it tremendously useful and valuable as a "building block" tool.

As mentioned the commands in the first two sections of the --help
blurb should work just fine with other loaders, and the reason the
sections exist in the --help text is to help making this clear.

> I feel it would make sense to offer some kind of configuration to
> teach bootctl(1) about these boot managers so that it can work for
> them, and not just systemd-boot.

So the commands in the first two sections already should work with any
boot loader implementing these specs. I am pretty sure that bootctl
should not be adjusted to specific boot loaders needleslly, instead
the bootloaders should just implement the specs...

Implementing the specs after all is not something that just is
relevant for bootctl only. After all there's a lot of hookup to the
two specs in logind too (for example, reboot into Windows, reboot into
boot loader entry xyz, and so on), or in the kexec-based reboot
functionality. And a lot of other stuff as well…

So we kept these things reasonably generic via making this specs so
that any other boot loader can be plugged in there. But I think real
interest in adding support for the specs in those other boot loaders
appears to be minimal unfortunately.

Note that the commands in the last section of the "bootctl --help"
text are something we never can make generic really. They are
specifically about installing sd-boot in the ESP, I see no avenue
about making this a grub installer, sorry...

> The second problem is because having sd-boot in the systemd source
> tree means that in order for Fedora to sign the boot manager EFI
> binaries, we have to lock down the systemd source package to the
> secure boot Koji build channel. This is unequivocally unacceptable
> from my point of view, as the restrictions around the secure boot
> channel make it realistically impossible for community contribution
> and maintenance of the package.

I don't follow. Where's the problem using the same source package for
two independently built RPM packages?

If Fedora wants to build systemd userspace packages one way,  and
systemd-boot another way, that's entirely fine actually. they can just
do that…

> Realistically, I think if we want to make movement on making
> systemd-boot fully supported in Fedora, the systemd-boot boot manager
> code itself should be split out into its own repository with its own
> release cadence, while bootctl(1) and related infrastructure remains
> in the systemd source tree and evolves to be able to manage arbitrary
> BLS-conformant boot managers.

Why though? I don't follow? as long as we provide you with a tarball
you can build your stuff from it shouldn't really matter if there's
more stuff in it you are not immediately interested in.

I mean, if you like I could do a "cp systemd-251.tar.gz
systemd-boot-251.tar.gz" for you if you want two tarballs instead of
one, but I don't see the point?

> This would also (hopefully) encourage other boot managers to support
> the Bootloader Spec configuration model, making it succeed as a
> semi-universal abstraction for boot manager configuration.

I don't think grub developers really care about bootctl. They probably
never heard of it I figure ;-).

I am not sure what the reason of the general disinterest from their
camp towards integration with userspace/systemd is. But I doubt that
a missing reorganization our tarballs is what is stopping them...

> We could then teach our tooling in Fedora to interact with
> bootctl(1) to do bootloader things, rather than having to create
> multiple tools and scripts to deal with this.

Well, you can use bootctl already just fine for the commands from the
first to sections in the --help text as mentioned — as long as your
boot loader of choice implements the spec.

> The alternative, of course, is to build sd-boot by having a second
> source package of the systemd code and setting it up to only build the
> boot stuff. This is painful for a variety of reasons: it guarantees we
> need to have some kind of synchronization point to ensure fixes and
> improvements are carried between the two.

Why would you need that synchronization point?

While sd-boot is built from the same systemd tree as the userspace
components it's totally OK to run it in combination with older or
newer userspace actually. We generally try to make this independent,
since for us it is important that you can use sd-boot to boot multiple
OSes, i.e. the boot loader is a single per-system resource, that needs
to be shared by all participating OSes installed on the same
system. i.e. in a theoretic system where suse, ubuntu and fedora all
support the boot loader spec properly and you install all three on the
same host, then they should be able to cooporate nicely, hence must be
able to work well if the boot loader they end up using is slightly
different from the one they themselves would install.

How do we achieve this? First of all, the interface between sd-boot
and userspace is relatively minimal and fixated in specs or
documentation (i.e. efi vars, and the aforementioned specs). Moreover,
the boot loader actually reports to userspace which features it
specifically supports via an efi var. This is in fact the
checkmark/crossmark table that bootctl shows you when you run it.

Note thta these days, there's som nontrivial code shared between the
EFI and userspace side of things. That's easy now because it comes
from the same build tree. It would be much harder and a
dependency/versioning mess if we'd split this up, and still share this
code. And in the future I actually would like to share *more* code
here, not less. After all, right now the boot loader spec parsers in
userspace (i.e. what bootctl does) and the ones in uefi space
(i.e. what sd-boot does) are distinct pieces of code. Which sucks, we
should unify that.

> It is more work from a maintenance perspective (especially around
> security stuff), and it doesn't really help with pushing the
> adoption of the Bootloader Spec as a whole.

I am not convinced. ;-)

Lennart

--
Lennart Poettering, Berlin