From: Andrew Ammerlaan <andrewammerlaan@gentoo.org>
To: gentoo-dev@lists.gentoo.org, gentoo-dev-announce@lists.gentoo.org
Subject: [gentoo-dev-announce] Testing request: sys-kernel/gentoo-kernel-bin[generic-uki]
Date: Tue, 2 Jan 2024 12:42:52 +0100 [thread overview]
Message-ID: <191261da-d4da-428c-a4f1-390ae8dbb3e9@gentoo.org> (raw)
Dear all,
First of all happy new year!
Those of you that have already synced the tree this year might have
already noticed that gentoo-kernel(-bin) has gained two new USE flags
yesterday. The first (USE=modules-compress) I think is pretty
self-explanatory, it installs all modules xz compressed.
The second new USE flag is USE=generic-uki, this will install the kernel
along with a prebuilt, experimental(!), generic initramfs and unified
kernel image. Let me explain first why this is something you might want
to use.
A Unified Kernel Image[1] combines the initramfs, cmdline, kernel and
some other things into a single EFI executable. This is great because it
allows the whole thing to be signed, and verified when booting with
Secure Boot[2] enabled. Whereas in the usual plain kernel image +
initramfs configuration, only the former is verified, leaving the
possibility of injecting something malicious into the initramfs.
We have supported generating your own Unified Kernel Images for some
time now. However, since building the UKI must always happen after
building the initramfs, which happens locally in postinst, this has so
far always relied on users generating and protecting their own
UKI-signing key. This is where USE=generic-uki comes in, it allows users
to take full advantage of the extra verification UKIs offer, without the
hassle of managing and protecting a custom signing key.
Though I know this works in my setups, there are still some open
questions and more testing in different setups is needed to determine
how generic our generic image actually is. We include many things in
this generic initramfs, but it is not feasible for me to test all of the
possible booting scenarios, so this is where we can use the help of the
community.
Some of the open questions are:
- OpenRC compatibility: Since this is a generic image and because it is
not possible to override a UKIs cmdline at boot when secure boot is
enabled, we cannot rely on root= to tell us where the root partition is.
Instead we rely on systemd-gpt-auto-generator[3] to dynamically
determine the correct partition layout. To what extent the inclusion of
systemd and its utilities in the initramfs impacts the possibility of
booting an openrc system with the generic UKI is still unknown. (Though
I have a suspicion that systemd will not be happy about handing over
control to another init system, and that therefore it might not work at
all.)
- Network booting: We include the dracut modules that should in theory
make the resulting UKI support network booting. However this is still
untested.
- Measured Boot: Ukify does the systemd-measure magic that should in
theory make it possible to unlock secrets conditionally on whether the
PCR registers match the predetermined value (i.e. Measured Boot). This
has not yet been tested (mostly because the TPM on my system is behaving
a bit odd, and I lack the experience with TPMs to determine why and how
to resolve it).
It would be great if folks could give our generic-uki a test drive to
help us explore what works, and what does not. All feedback is welcome
on #gentoo-dist-kernel or via bug report.
Here's a brief list of steps to set this up:
- Enable USE=generic-uki on gentoo-kernel-bin
- If installkernel-systemd is used, configure it as follows in
/etc/kernel/install.conf:
layout=uki
uki_generator=none
initrd_generator=none
- If installkernel-gentoo is used, enable USE=uki
- (re-)emerge gentoo-kernel-bin
- If shim/mokutil is used, import our certificate:
mokutil --import /usr/src/linux-6.6.9-gentoo-dist/certs/signing_key.x509
- If shim/mokutil is not used, but secureboot is still desired, ensure
our certificate will be accepted by the UEFI (steps depend on the vendor)
- Ensure a known-working alternative kernel/UKI is also present
- If refind is used, configure it to find the new UKI. If systemd-boot
is used it will be auto-discovered and no further setup is required.
- Reboot
If any of the documentation on the wiki is unclear, then please also let
me know so I can improve it.
Some frequently asked questions:
- What bootloaders are supported?: systemd-boot, refind. And possibly
version 2.12 and up of grub.
- Can I use the prebuilt generic initramfs image, without using the
generic UKI, or use the generic initramfs to generate my own custom
UKI?: Yes, see [5].
- Can I combine this with USE=modules-compress?: Yes
- Are boot splashes supported?: No, including plymouth in the initramfs
requires including the gpu drivers and firmware as well. These files are
huge and they are many. At this time the cost of the increased uki and
gpkg size is not something we are willing to pay.
If there are any other questions feel free to drop by #gentoo-dist-kernel.
Best regards,
Andrew
[1] https://wiki.gentoo.org/wiki/Unified_kernel_image
[2] https://wiki.gentoo.org/wiki/Secure_Boot
[3]
https://wiki.gentoo.org/wiki/Systemd#Automatic_mounting_of_partitions_at_boot
[4] https://wiki.gentoo.org/wiki/User:Ajak/Measured_Boot
[5] https://wiki.gentoo.org/wiki/Project:Distribution_Kernel#Generic_UKI
reply other threads:[~2024-01-02 12:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=191261da-d4da-428c-a4f1-390ae8dbb3e9@gentoo.org \
--to=andrewammerlaan@gentoo.org \
--cc=gentoo-dev-announce@lists.gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox