Lennart Pottering proposed a new Linux verified boot architecture

Lennart Poettering has published a proposal to modernize the boot process of Linux distributions, aimed at solving existing problems and simplifying the organization of a full-fledged verified boot, confirming the authenticity of the kernel and the underlying system environment. The changes required 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.

The proposed changes are reduced to the creation of a single universal UKI (Unified Kernel Image) image that combines the Linux kernel image, the handler for loading the kernel from UEFI (UEFI boot stub) and the initrd system environment loaded into memory, used for initial initialization at the stage before mounting the root FS. Instead of an initrd RAM disk image, the entire system can be packaged in the UKI, allowing the creation of fully verified system environments that are loaded into RAM. UKI-image is made in the form of an executable file in PE format, which can be loaded not only using traditional bootloaders, but is directly called 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 Linux distributions use the chain β€œfirmware β†’ digitally signed Microsoft shim layer β†’ digitally signed distribution GRUB bootloader β†’ digitally signed distribution Linux kernel β†’ unsigned initrd environment β†’ root FS” in the initialization process. The lack of initrd verification in traditional distributions creates security problems, since, among other things, this environment extracts keys to decrypt the root FS.

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

Add a comment