From Fedora Project Wiki
Line 51: Line 51:
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 unrealistic, there are too many features depending on the current
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 😃
initrd workflow. Thats why there is 'Phase 1' in title, so we can have more Phases in future releases 😊


Problems of the current initrd workflow:
A host-specific initrd / command line is needed today for:


* optional dracut modules, initrd rebuild on installed machine needed to enabled them.
* features needing optional dracut modules (initrd rebuild needed to enabled them).
* configuration / secrets baked into the initrd.
* 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] can help with this one.
** root filesystem being the most important one.  [https://systemd.io/DISCOVERABLE_PARTITIONS/ Discoverable partitions] allow to remove this.


Phase 1 goals (high priority):
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.  Booting modern physical machines with standard setup (i.e. boot from local sata/nvme storage) too shouldn't be much of a problem.
* 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.
* Update kernel install scripts so unified kernels are installed and updated properly.
* Add bootloader support for unified kernel images.  Add [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images unified kernel bls support] to grub2, or support using systemd-boot, or both.
* Add bootloader support for unified kernel images.  Add [https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-2-efi-unified-kernel-images unified kernel bls support] to grub2, or support using systemd-boot, or both.
Line 69: Line 68:
Phase 1 goals (lower priority, might move to Phase 2):
Phase 1 goals (lower priority, might move to Phase 2):


* Measurement (details todo).
* Add proper discoverable partitions support to installers (anaconda, image builder, ...).
* Discoverable partitions (details todo).
** Temporary workaround possible: set types using sfdisk in %post script.
* Add proper systemd-boot support to installers.
** 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 goals (longer-term stuff which is not realistic for F38).
Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38).


* initrd extensions (details todo).
* Move away from using the kernel command line for configuration.
* 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.
 
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.


== Feedback ==
== Feedback ==

Revision as of 06:30, 27 September 2022


Unified Kernel Support Phase 1

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Add support for unified kernels images to Fedora.

Owner

Current status

  • Targeted release: Fedora Linux 38
  • Last updated: 2022-09-27
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

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.

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.

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 😃

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

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

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.
  • Add proper systemd-boot support to installers.
    • 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.

Phase 2/3 goals (longer-term stuff which is not realistic to complete for F38).

  • Move away from using the kernel command line for configuration.
  • 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. 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.

Feedback

Benefit to Fedora

Scope

  • Proposal owners:
  • Other developers:
  • 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

How To Test

User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


Documentation

N/A (not a System Wide Change)

Release Notes