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

Wed Apr 27 12:55:55 UTC 2022

On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek
<zbyszek at in.waw.pl> wrote:
>
> 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 think this is probably a distraction from this discussion, but sure
I guess I can answer: I fundamentally dislike systemd-boot because I
feel it's not a very user-friendly boot manager because of its
absolutely spartan interface. I'm much more of a fan of rEFInd[1],
which provides a feature-rich and user-friendly EFI boot manager[2].

While I get the idea that people shouldn't spend a lot of time at the
boot menu, it's very clear that other platforms (Windows and macOS)
spend a great deal of time making their boot environments friendly and
useful so that when they have to be there, it's not a bad place. I
like having the same for my Linux environments too.

I use rEFInd on my MacBooks running Fedora Linux and I really like it.
A couple of other Linux distributions have also adopted rEFInd as an
option (notably Mageia did). One of the things I'd like to have as a
positive outcome from this would be to have the infrastructure in
place to make it appealing for rEFInd to support the Bootloader
Spec[3] in addition to the Discoverable Partition Spec[4] it already
supports today.

[1]: https://www.rodsbooks.com/refind
[2]: https://www.rodsbooks.com/refind/features.html
[3]: https://systemd.io/BOOT_LOADER_SPECIFICATION/
[4]: https://systemd.io/DISCOVERABLE_PARTITIONS/

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

I'm purely talking about EFI boot managers. I would like bootctl(1) to
be able to lifecycle any BLS-conformant EFI boot manager.

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

Sadly, I think this is intentionally under-documented. It took a *ton*
of research to figure this out.

Essentially, the Koji build channel for secure boot is made up of three things:

* an ACL list of users allowed to do builds (which usually is one or two people)
* builders with an HSM with a configured mock mountpoint for certs
* pesign with configured macros and mock helper pointing to said certs
on the builder

These three things are designed to comply with Microsoft's
requirements for managing access to produce valid builds.

At least for Fedora, historically this has meant that packages that
are in this channel must be Red Hat employees who are able to work
under tight restrictions to also deal with embargos around secure boot
stuff too. I suspect this is still true, despite nobody specifically
confirming or denying this today. But it is notable that the only
packages under these channels are shim, grub2, and the kernel and all
of them can't have community maintainers.

The mechanics of actually producing a properly signed build are
simple: pesign runs as a daemon on the builders in this channel. The
package also installs mock and rpmbuild helpers that are configured to
pick up and auto-authorize (bind the mockbuild user to the pesign
group) so that the signing process works by calling %pesign in the
package build to generate signed EFI binaries. Part of the reason this
is obfuscated so much is that the existing Fedora packages that do
undergo this signing mechanism predate the existence of the macros,
and so do it completely manually.

For sd-boot, it'd be making sure the package is "ExclusiveArch:
%{efi}", then in %install, you'd do:

pushd %{buildroot}%{_prefix}/lib/systemd/boot/efi
%pesign -s -i systemd-boot%{efi_arch}.efi -o systemd-boot%{efi_arch}.efi.signed
popd

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

It's... not a nice world. I described what it actually is above, and
frankly that's an unpleasant reality.

--
真実はいつも一つ！/ Always, there's only one truth!