From Fedora Project Wiki
No edit summary
 
(31 intermediate revisions by 3 users not shown)
Line 2: Line 2:


= Unified Kernel Support Phase 1 =
= Unified Kernel Support Phase 1 =
{{Change_Proposal_Banner}}


== Summary ==
== Summary ==
Line 22: Line 20:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF38]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 39: Line 37:
ON_QA -> change is fully code complete
ON_QA -> change is fully code complete
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/EDQVGL6Y6D75HS5NGLIBVPHCW23SPGEG/ devel thread]
* Tracker bug: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2926 #2926]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=2159490 #2159490]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/950 #950]


== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
The goal is to move away from initrd images being generated on the installed machine.  They are generated while building the kernel package instead, then shipped as part of a unified kernel image.
The goal is to move away from initrd images being generated on the installed machine where possibleThe initrd is generated while building the kernel package instead, then shipped as part of a unified kernel image (UKI).


A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature.  The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot.
A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature.  The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot.
Line 51: Line 50:
Main motivation for this move is to make the distro more robust and more secure.
Main motivation for this move is to make the distro more robust and more secure.


Switching the whole distro over to unified kernels quickly is not realistic though.  Too many features are depending on the current workflow with a host-specific initrd (and host-specific kernel command line), which is fundamentally incompatible with unified kernels where everybody will have the same initrd and command line. Thats why there is 'Phase 1' in title, so we can have more Phases in future releases 😃
Supporting unified kernels for all use cases quickly is not realistic though.  Too many features are depending on the current workflow with a host-specific initrd (and host-specific kernel command line), which is fundamentally incompatible with unified kernels where everybody will have the same initrd and command line. Thats why there is 'Phase 1' in title, so we can have more Phases in future releases 😃
 
long term plan:
* Phase 1: Get the basic building blocks into place, so it is possible to work with and develop for UKIs in virtual machines.
* Phase 2+: Expand UKI support, tackling the use cases which depend on a host-specific initrd or command line (see below) one by one.
* Phase X: Once UKIs have feature parity with non-UKI kernels discuss whenever they should be used by default everywhere (specific use cases like cloud images might switch earlier).
* NOT planed: remove support for non-UKI kernels.


A host-specific initrd / command line is needed today for:
A host-specific initrd / command line is needed today for:


* features needing optional dracut modules (initrd rebuild needed to enabled them).
* features needing optional dracut modules (initrd rebuild needed to enable them).
* configuration / secrets baked into the initrd (booting from iscsi for example).
* configuration / secrets baked into the initrd (booting from iscsi for example).
* configuration being specified on the kernel command line.
* configuration being specified on the kernel command line.
** root filesystem being the most important one.  [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] allow to remove this.
** root filesystem being the most important one.  [https://uapi-group.org/specifications/specs/discoverable_partitions_specification/ Discoverable partitions] allow to remove this.
 
systemd has some building blocks which can be used, although none of them are used by fedora today.  [https://www.freedesktop.org/software/systemd/man/systemd-creds.html systemd credentials] can be used for secrets (also for configuration).  The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html unified kernel stub] can load credentials from the ESP.  The unified kernel stub can also load [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html extensions] from the ESP, which can possibly be used to replace optional dracut modules.


Phase 1 goals (high priority):
Phase 1 goals (high priority):
Line 70: Line 77:
* Add proper discoverable partitions support to installers (anaconda, image builder, ...).
* Add proper discoverable partitions support to installers (anaconda, image builder, ...).
** Temporary workaround possible: set types using sfdisk in %post script.
** Temporary workaround possible: set types using sfdisk in %post script.
* Add proper systemd-boot support to installers.
** When using btrfs: configure 'root' subvolume as default volume.
** Temporary workaround possible: run 'bootctl install' in %post script.
* Better measurement and remote attestation support.
** store kernel + initrd hashes somewhere (kernel-hashes.rpm ?) to allow pre-calculate TPM PCR values.
** avoid using grub2 (measures every config file line executed which is next to impossible to pre-calculate).
* Switch cloud images to use unified kernels.
* Switch cloud images to use unified kernels.


Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38).
Phase 2/3 goals: moved to [[ Changes/Unified_Kernel_Support_Phase_2 ]]


* Move away from using the kernel command line for configuration.
Architecture notes:
* Move away from storing secrets in the initrd.
* Handle dracut optional modules in a different way.


systemd has some building blocks which can be used, although none of them are used by fedora today. [https://www.freedesktop.org/software/systemd/man/systemd-creds.html systemd credentials] can be used for secrets (also for configuration).  The [https://www.freedesktop.org/software/systemd/man/systemd-stub.html unified kernel stub] can load credentials from the ESP.
* x86_64 uefi: main target
 
* x86_64 bios: experimental grub patches to boot UKIs exist, to allow hybrid uefi/bios cloud images with UKIs.
The unified kernel stub can also load [https://www.freedesktop.org/software/systemd/man/systemd-sysext.html extensions] from the ESP, which can possibly be used to replace optional dracut modules.
* aarch64: depends on sorting out the compressed kernel problem (see [https://github.com/systemd/systemd/issues/23788 systemd issue 23788])
** kernel got CONFIG_EFI_ZBOOT support in 6.1
** kernel-ark CI seems to not be ready for it (yet?)
* ppc64le: uses grub, so building UKIs with a dummy efi stub and letting grub unpack them (simliar to x86_64 bios) should be possible without too much trouble.
** Not sure this is worth the effort.
** Probably a good idea to wait for x86_64 experiences before deciding on this one.
** Some ppc platforms (pseries) have non-EFI secure boot support which should be looked at too.
* s390x: no plans


== Feedback ==
== Feedback ==
Line 125: Line 133:
* Proposal owners:
* Proposal owners:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** Update kernel build to create unified kernel sub-package.
*** part one: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2179 PR#2179] (merged).
*** part two: [https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2175 PR#2175]. (merged)


* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
** grub2: add unified kernel support
*** wip code at <del>https://github.com/osteffenrh/grub2/</del><BR>https://github.com/osteffenrh/grub2-blscfg/commits/blscfg-unified-kernel-f38
** installer(s): add support for discoverable partitions.
*** [https://bugzilla.redhat.com/show_bug.cgi?id=1075288 Bug#1075288] (done in python-blivet-3.7.0-1.fc38)


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 162: Line 178:
-->
-->


* dnf copr enable kraxel/unified.kernel
Try on a existing (uefi) system:
* dnf install kernel-unified-virt
* make sure you are running fedora 37 or rawhide.
* reboot
* make sure you have secure boot turned off (the grub2 packages from the copr repo are not signed)
(more details TBD, kickstart example TBD)
* make sure your root filesystem has type "Linux root (x86-64)" (use `fdisk -l` to check).
** should that not be the case use the fdisk tag command ('t') to change the partition type (you can also use gnome disks; select the partition and then Edit Partition -> Type).
* when using btrfs: make sure the 'root' subvolume is set as default volume.
* `dnf copr enable kraxel/unified.kernel`
* `dnf update "grub2*"`
* `dnf install kernel-uki-virt`
* `reboot`
You should find two entries in the grub2 boot menu, one for classing kernel with separate initrd and one for the unified kernel image.  Both should boot fine.
 
The https://gitlab.com/kraxel/fedora-uki project has kickstart files and helper scripts for generating virtual machine images.
* image using grub2-efi: https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-grub2-x64.ks
* image using systemd-boot: https://gitlab.com/kraxel/fedora-uki/-/raw/master/kickstart/fedora-uki-sdboot-x64.ks
 
Prebuilt virtual machine images are available from https://www.kraxel.org/fedora-uki/.


== User Experience ==
== User Experience ==

Latest revision as of 17:32, 26 March 2023


Unified Kernel Support Phase 1

Summary

Add support for unified kernels images to Fedora.

Owner

Current status

Detailed Description

The goal is to move away from initrd images being generated on the installed machine where possible. The initrd is generated while building the kernel package instead, then shipped as part of a unified kernel image (UKI).

A unified kernel image is an all-in-one efi binary containing kernel, initrd, cmdline and signature. The secure boot signature covers everything, specifically the initrd is included which is not the case when the initrd gets loaded as separate file from /boot.

Main motivation for this move is to make the distro more robust and more secure.

Supporting unified kernels for all use cases quickly is not realistic though. Too many features are depending on the current workflow with a host-specific initrd (and host-specific kernel command line), which is fundamentally incompatible with unified kernels where everybody will have the same initrd and command line. Thats why there is 'Phase 1' in title, so we can have more Phases in future releases 😃

long term plan:

  • Phase 1: Get the basic building blocks into place, so it is possible to work with and develop for UKIs in virtual machines.
  • Phase 2+: Expand UKI support, tackling the use cases which depend on a host-specific initrd or command line (see below) one by one.
  • Phase X: Once UKIs have feature parity with non-UKI kernels discuss whenever they should be used by default everywhere (specific use cases like cloud images might switch earlier).
  • NOT planed: remove support for non-UKI kernels.

A host-specific initrd / command line is needed today for:

  • features needing optional dracut modules (initrd rebuild needed to enable them).
  • configuration / secrets baked into the initrd (booting from iscsi for example).
  • configuration being specified on the kernel command line.

systemd has some building blocks which can be used, although none of them are used by fedora today. systemd credentials can be used for secrets (also for configuration). The unified kernel stub can load credentials from the ESP. The unified kernel stub can also load extensions from the ESP, which can possibly be used to replace optional dracut modules.

Phase 1 goals (high priority):

  • Ship a unified kernel image as (optional) kernel sub-rpm. Users can opt-in to use that kernel by installing the sub-rpm. Initial focus is on booting virtual machines where we have a relatively small and well defined set of drivers / features needed. Supporting modern physical machines with standard setup (i.e. boot from local sata/nvme storage) too should be easy.
  • Update kernel install scripts so unified kernels are installed and updated properly.
  • Add bootloader support for unified kernel images. Add unified kernel bls support to grub2, or support using systemd-boot, or both.

Phase 1 goals (lower priority, might move to Phase 2):

  • Add proper discoverable partitions support to installers (anaconda, image builder, ...).
    • Temporary workaround possible: set types using sfdisk in %post script.
    • When using btrfs: configure 'root' subvolume as default volume.
  • Switch cloud images to use unified kernels.

Phase 2/3 goals: moved to Changes/Unified_Kernel_Support_Phase_2

Architecture notes:

  • x86_64 uefi: main target
  • x86_64 bios: experimental grub patches to boot UKIs exist, to allow hybrid uefi/bios cloud images with UKIs.
  • aarch64: depends on sorting out the compressed kernel problem (see systemd issue 23788)
    • kernel got CONFIG_EFI_ZBOOT support in 6.1
    • kernel-ark CI seems to not be ready for it (yet?)
  • ppc64le: uses grub, so building UKIs with a dummy efi stub and letting grub unpack them (simliar to x86_64 bios) should be possible without too much trouble.
    • Not sure this is worth the effort.
    • Probably a good idea to wait for x86_64 experiences before deciding on this one.
    • Some ppc platforms (pseries) have non-EFI secure boot support which should be looked at too.
  • s390x: no plans

Feedback

Benefit to Fedora

  • Better secure boot support (specifically the initrd is covered by the signature).
  • Better confidential computing support (measurements are much more useful if we know what hashes to expect for the initrd).
  • More robust boot process (generating the initrd on the installed system is fragile, root cause for kernel bugs reported is simply a broken initrd sometimes).

Scope

  • Proposal owners:
    • Update kernel build to create unified kernel sub-package.
    • installer(s): add support for discoverable partitions.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives:

Upgrade/compatibility impact

None (using unified kernel is opt-in for Phase 1).

How To Test

Try on a existing (uefi) system:

  • make sure you are running fedora 37 or rawhide.
  • make sure you have secure boot turned off (the grub2 packages from the copr repo are not signed)
  • make sure your root filesystem has type "Linux root (x86-64)" (use fdisk -l to check).
    • should that not be the case use the fdisk tag command ('t') to change the partition type (you can also use gnome disks; select the partition and then Edit Partition -> Type).
  • when using btrfs: make sure the 'root' subvolume is set as default volume.
  • dnf copr enable kraxel/unified.kernel
  • dnf update "grub2*"
  • dnf install kernel-uki-virt
  • reboot

You should find two entries in the grub2 boot menu, one for classing kernel with separate initrd and one for the unified kernel image. Both should boot fine.

The https://gitlab.com/kraxel/fedora-uki project has kickstart files and helper scripts for generating virtual machine images.

Prebuilt virtual machine images are available from https://www.kraxel.org/fedora-uki/.

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism:
    • Probably none (unified kernel images are opt-in for Phase 1).
    • In case we tried switching the cloud images to unified kernels: revert the kickstart config changes.
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No

Documentation

N/A (not a System Wide Change)

Release Notes