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.
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.
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.
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
Thanks,
Overall, those are really small things, but progress has been very slow.
[4] https://uapi-group.org/specifications/specs/discoverable_partitions_specification/
[5] https://bugzilla.redhat.com/show_bug.cgi?id=2121912
[1] https://medium.com/@umglurf/full-uefi-secure-boot-on-fedora-using-signed-initrd-and-systemd-boot-3ff2054593ab
Yeah. This blog story reflects the mess we have right now. This level of
complexity and risk is not suitable for the general user. There's just too much
chance of something going wrong and the system being broken. We need to cut the
number of steps down by 90%.
Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
