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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Apr 26, 2022 at 07:12:02PM -0400, Neal Gompa wrote:
> Hey all,

Hi Neal,

thank you for starting the discussion. I think it'd be good to figure
out what are the high-level options we have as a community…

> 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

You mentioned that a few times, and we (at least Lennnart and I) have
asked for details. If there's something important missing from sd-boot,
we would like to know.

> I *am* a fan of a lot of the mechanisms around it, and I think it
> would be valuable for us to adopt more of that in Fedora. To that
> end, that means making it easier for people to fully adopt
> systemd-boot on their systems in Fedora with minimal effort (ideally
> just a kickstart or Anaconda flag if desired).

Yeah. While I don't think we're ready to propose it as the default,
we definitely would like it to be trivial to switch to it if somebody
wants to.

> From my point of view as someone working on several Fedora variants
> and would like to provide more optionality around this, there are a
> couple of issues:
> 
> * bootctl(1) appears to be tightly coupled to sd-boot

This is a misunderstanding of the our development goals of systemd
(the project) and sd-boot. As far as possible, generic interfaces are used.

Starting from the bottom: the boot loader specification is designed
to be completely generic and independent of the boot loader and independent
of the userspace tools used to configure the boot loader. Similarly,
most bootctl commands are implemented using generic functionality
(either EFI or any bootloader implementing the boot loader specification).
And stuff like 'bootctl status' and 'systemd-analyze blame' use interfaces
that are completely generic and any bootload can provide the appropriate
information to the operating system (see https://systemd.io/BOOT_LOADER_INTERFACE/).
So bootctl is NOT coupled to sd-boot, except for some specific parts
explicitly documented to be about sd-boot, currently the
install/update/uninstall verbs and random-seed support.

> * sd-boot is part of the systemd source tree
> 
> 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. 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.

bootctl could be taught to install other EFI stuff. It'd probably be a
matter of specifying a different glob when looking for files to copy.
I'm not sure if we want to get into the business of installing non-EFI
stuff… What exactly do you have in mind?

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

Do you have more information about "secure boot Koji build channel"?
I was asking around, and I learnt that I need to read up on "pesign",
but not much beyond that. What restrictions does it place on the build?

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

This is not so simple. systemd-boot shared source code with the bootctl
and other parts of the tree (see src/fundamental/), and in general
we want to move towards not having seperate implementations, but to
share as much code as possible. Having this all in one tree makes things
much easier. Splitting out to a separate repo would make development
much harder and is somethign that we'd very much want to avoid.

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

Yes.

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

Yeah, this doesn't sound nice. But let's talk about building everything
from the same source package first.

Zbyszek