On Tue, Jun 13, 2023 at 07:55:09AM -0500, Jeremy Linton wrote:
Hi,
On 6/5/23 03:24, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jun 02, 2023 at 05:25:22PM -0700, Luya Tshimbalanga wrote:
> > Hello team,
> >
> > I would like to bring back the topic related to the selection of bootloader
> > notably either GRUB2 and systemd-boot. With the recent adoption on UKI
> > kernel, it would be great to get systemd-boot ready for at least Fedora 39
> > which is useful for devices like laptops. Currently, some methods allow to
> > install systemd-boot with extra step to keep supporting secure boot while
> > preserving GRUB2 [1]. What is the missing step to enable secure boot for
> > systemd-boot without at least keeping GRUB 2?
>
> Hi Luya,
>
> my goal is to have systemd-boot built as a ready-to-install Fedora package
> with a Fedora signature for SecureBoot. The signature would use a different
> certificate than grub2, and would not be trusted by our shim build. (This
> way, we don't have to touch the complicated issue of making shim trust
sd-boot.)
> Users would be able to self-enroll those sd-boot singing keys on their machines,
> getting reasonable protection from SecureBoot and being able to build
> useful policies for tpm-encrypted secrets.
I tend to agree this is the right way to use systemd-boot although users
depending on 3rd party modules will be again locked out of the secure boot
path without the shim + MOKs. That support exists in systemd-boot today but
it might be a good idea to provide a switch to disable the shim support in
sdboot if the plan is to have a clean secure boot setup without MOKs. AKA
systemd-boot-signed and a systemd-boot-signed-for-shim package.
>
> Unfortunately, this requires releng to adjust the infrastructure to do the
> signing, and this is not progressing at all [1].
>
> Also, there has been work to add support for sd-boot to Anaconda [2,3].
> There has been more progress there, but what we have is not a complete solution.
It is with the comps change below and the acceptance of the sdbubby package
which is shimming things like kdumpctl to the systemd interface. Granted its
not complete given the secure boot path hasn't been solved, but it does
allow for testing a machine that can be updated, and generally works
transparently. Once a signed package is available it should be fairly simple
to assure the secure boot keys that need enrolling are positioned on the ESP
for systemd-boot to enroll during the next reboot.
>
> [1]
https://pagure.io/releng/issue/10765
> [2]
https://bugzilla.redhat.com/show_bug.cgi?id=2106706
> [3]
https://github.com/rhinstaller/anaconda/pull/4368
>
> In general, I think it'd be nice to make the process of installing sd-boot much
> much simpler than it is currently. 'bootctl install' takes care of
installation
> process, if the system already has the expected layout. So the installation
procedure
> for Fedora should be just 'dnf install …' of a single package. But this
doesn't
> currently work because of a few issues:
>
> 1. the /boot partition is formatted with ext4
I don't think this is really a problem with the current anaconda +
systemd-boot-unsigned + sdubby package. If the user default installs with
inst.sdboot they get a separate /boot partition, and it continues to hold
parts of the kernel debug/etc packages that aren't needed for boot. The
kernel, initrd and loader entries have all been moved to the /boot/efi ESP
partition under the assumption that systemd-boot systems will have larger
ESPs and the /boot partition can be removed in its entirety. This works
quite well today if the user uses the inst.sdboot option and simply deletes
the /boot partition with the partition tools in anaconda.
It is possible to not have the XBOOTLDR partition (i.e. /boot), and
only use ESP (i.e. /efi or /boot/efi) to hold kernels. In particular,
when the ESP is created by the installer. But in the general case, we
want XBOOTLDR to also be readable by the firmware if it is present.
This matters for two cases:
- installation onto systems where ESP already exists (e.g. dualboot)
- switching from grub2 to sd-boot on previously installed systems.
So while it's not a blocker, in the long run we should make this switch.
> 2. partitions don't have parttype uuids conforming to
Discoverable Partitions Spec [4]
> (or has this been fixed? I need to check.)
I'm not sure this is needed either given the kernel + initrd is on the ESP.
We want for other reasons too. It makes things autodiscoverable and
just nicer in general.
> 3. grub2 and shim carry files directly in their rpm payload,
hardcoding paths and
> causing any changes to layout to conflict with what rpm thinks about the file
system.
> (This part was discussed on fedora-devel recently too.)
The anaconda inst.sdboot option explicitly doesn't install grub, grubby,
grub efi tools, nor shim. Although as noted in the review comments the
sdubby package "pins" the install location that bootctl/etc are aware of.
Which IMHO isn't a problem given the above.
https://bugzilla.redhat.com/show_bug.cgi?id=2134972
And as I mention in that ticket I'm not sure I view it as a problem either
since fedora has an existing filesystem layout, and something has to make
the choice about where the files are located and that is usually the
responsibility of rpm/etc on fedora systems since it also aids in auditing
the files, dealing with updates, etc. I'm personally not super happy using
`bootctl install` to move the EFI bootloader executable to the ESP, since I
think its totally unnecessarily now that systemd-boot its its own package,
but that is what anaconda is doing at the moment.
ESP and XBOOTLDR are shared with other systems. The installer shouldn't
just assume that it can do whatever it wants there. So this means that
the logic to do changes there must be different than just "install the
file from the rpm". And then if we need to use special handling in some
cases, it makes sense to use the same method in all cases.
Nor am I entirely sure the default location it likes to install
itself is
"correct" if its being installed without shim, but it does "Work".
> 4. grub2 and grubby and other packages are part of Requires chain in packages [e.g.
5].
> Point 3. makes this more of a problem.
Yes, hence:
https://pagure.io/fedora-comps/pull-request/838 which is the
minimal change to make it all work.
So I filed a change ticket along these lines too:
https://fedoraproject.org/wiki/Changes/cleanup_systemd_install
This looks interesting. Thank your for working on thsi.
(I think the title could be improved. We generally use
"Capitalized_Titles_with_Underscores" and this isn't really about
"systemd install".)
Zbyszek