Lennart Poettering has published a proposal to modernize the boot process. Linux-distributions, aimed at addressing existing issues and simplifying the organization of a fully verified boot process that confirms the validity of the kernel and the underlying system environment. The changes required to implement the new architecture have already been incorporated into the systemd codebase and affect components such as systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase, and systemd-creds.
The proposed changes boil down to the creation of a single universal image UKI (Unified Kernel Image), which combines the kernel image Linux, a handler for loading the kernel from UEFI (UEFI boot stub), and an initrd system environment loaded into memory, used for initialization before mounting the root filesystem. Instead of an initrd RAM disk image, the entire system can be packaged into a UKI, allowing for the creation of fully verified system environments loaded into RAM. The UKI image is packaged as an executable file in PE format, which can be loaded not only by traditional bootloaders but also directly from the UEFI firmware.
The ability to call from UEFI allows you to use a digital signature integrity and validity check that covers not only the kernel, but also the contents of the initrd. At the same time, support for calling from traditional bootloaders allows you to save such features as the delivery of several versions of the kernel and automatic rollback to a working kernel in case problems with the new kernel are detected after installing the update.
Currently, most distributions Linux The initialization process uses the following chain: firmware → shim layer certified with a Microsoft digital signature → GRUB bootloader certified with a distribution digital signature → kernel certified with a distribution digital signature Linux → unverified initrd environment → root file system." The lack of initrd verification in traditional distributions creates security issues, since, among other things, this environment is used to extract keys for decrypting the root file system.
Verification of the 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 greatly complicates the organization of verification when using the SecureBoot mode (to verify the initrd, the user needs to generate his keys and load them into the UEFI firmware). In addition, the existing boot organization does not allow using information from the TPM PCR (Platform Configuration Register) registers to control the integrity of user-space components other than shim, grub, and the kernel. Among the existing problems, the complication of updating the bootloader and the inability to restrict access to keys in TPM for older OS versions that have become irrelevant after installing the update are also mentioned.
The main goals of implementing the new boot architecture are:
- Providing a fully verified download process, covering all stages from firmware to user space, and confirming the validity and integrity of the downloaded components.
- Binding of controlled resources to TPM PCR registers with division by owners.
- Ability to precalculate PCR values based on kernel boot, initrd, configuration, and local system ID.
- Protection against rollback attacks associated with rollback to the previous vulnerable version of the system.
- Simplify and improve the reliability of updates.
- Support for OS updates that do not require re-applying or local provisioning of TPM-protected resources.
- Readiness of the system for remote certification to confirm the correctness of the bootable OS and settings.
- The ability to attach sensitive data to certain boot stages, for example, extracting encryption keys for the root FS from the TPM.
- Provide a secure, automatic, and silent process for unlocking keys to decrypt a drive with a root partition.
- The use of chips that support the TPM 2.0 specification, with the ability to fallback to systems without TPM.
Source: opennet.ru
