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

[Neal Gompa <ngompa13@xxxxxxxxx>]

On Wed, Apr 27, 2022 at 8:55 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Wed, Apr 27, 2022 at 6:47 AM Zbigniew Jędrzejewski-Szmek
> <zbyszek@xxxxxxxxx> 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
>

Oh, and you need to add "BuildRequires: pesign" and "BuildRequires:
efi-srpm-macros" stanzas to your spec.



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