They propose to modernize the Linux boot process

The new Linux boot will work well into the future with a focus on robustness and simplicity.

Lennart Poettering (the creator of Systemd) made it known recently a proposal to modernize the boot process of the distributions of Linux, with the aim of solving existing problems and simplify the organization of a full verified boot, confirming the authenticity of the kernel and the underlying system environment.

Proposed Changes are reduced to creation of a single universal UKI image (Unified Kernel Image) which merges the kernel image Linux driver to load the kernel from UEFI (UEFI boot stub) and the system environment initrd loaded into memory, used for initial initialization at the stage before mounting the FS.

Instead of a ramdisk image initrd, the whole system can be packed in the UKI, allowing the creation of fully verified system environments that are loaded into RAM. The UKI image is packaged as an executable file in PE format, which can not only be loaded with traditional bootloaders, but can also be called directly from the UEFI firmware.

The ability to call from UEFI allows the use of a digital signature validity and integrity check which covers not only the kernel, but also the contents of the initrd. At the same time, support for calls from traditional bootloaders allows saving features such as delivering multiple kernel versions and automatically rolling back to a working kernel in case problems with the new kernel are detected after installing the latest kernel. update.

Currently, most Linux distributions use chain "firmware → digitally signed Microsoft shim layer → digitally signed distribution GRUB bootloader → digitally signed distribution Linux kernel → unsigned initrd environment → FS root" in the initialization process. Missing initrd check in traditional distributions creates security problems, since, among other things, this environment extracts keys to decrypt the FS root.

Verification of initrd image is not supported, since this file is generated on the user's local system and cannot be certified by the distribution's digital signature, which makes it very difficult to organize verification when using SecureBoot mode (to verify the initrd, the user needs to generate your keys and load them into the UEFI firmware).

In addition, the existing boot organization does not allow the use of information from the TPM PCR registers (Platform Configuration Registry) to control the integrity of userspace components other than shim, grub, and kernel. Among the existing problems, the complication of updating the bootloader and the inability to restrict access to keys in the TPM for older versions of the operating system that have become irrelevant after installing the update are also mentioned.

The main objectives of implementing the new boot architecture:

• Provide a fully verified download process, covering all stages from firmware to user space, and confirming the validity and integrity of downloaded components.
• Linking of controlled resources to TPM PCR registers with separation by owners.
• Ability to precompute PCR values ​​based on kernel boot, initrd, configuration, and local system ID.
• Protection against rollback attacks associated with reverting to the previous vulnerable version of the system.
• Simplify and improve the reliability of updates.
• Support for OS upgrades that do not require reapplying or provisioning TPM-protected resources locally.
• Preparing the system for remote certification to confirm the correctness of the operating system and boot configuration.
• The ability to attach sensitive data to certain boot stages, for example by extracting encryption keys for the FS root from the TPM.
• Provide a safe, automatic and silent process to unlock keys to decrypt a drive with a root partition.
• The use of chips that support the TPM 2.0 specification, with the ability to fall back to systems without a TPM.

The necessary changes to implement the new architecture are already included in the systemd codebase and affect components such as systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase, and systemd-creds.

Finally if you are interested in knowing more about it, you can check the details in the following link