Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 8. Configuring RHEL on Public Cloud Platforms with UKI

To ensure that a Red Hat Enterprise Linux (RHEL) instance has a secured boot process from an untrusted storage such as confidential virtual machine (CVM) on a public cloud platform, use Unified Kernel Image (UKI).

8.1. Introduction to Unified Kernel Image
Copy link

To extend the secure boot protection throughout the entire boot chain, use Unified Kernel Image (UKI).

Components of UKI

Unified Kernel Image (UKI) is a Unified Extensible Firmware Interface (UEFI) Portable Executable (PE) binary for the UEFI firmware environment, which bundles the essential components of an operating system. UKI binary components extend the Secure Boot mechanism with initramfs and the kernel command line. Initramfs is a part of the Linux startup process, while the kernel command line gives you limited access to define parameters. Components are as follows:

  • The .linux section stores the Linux kernel image.
  • The .initrd section stores the initial RAM filesystem initramfs.
  • The .cmdline section stores the kernel command line.
  • Additional sections, such as .sbat.
  • The Red Hat signature.
Features of RHEL UKI with pre-built initramfs
  • Prohibits any malicious agent or component to alter any objects in the boot chain.
  • Due to pre-built initramfs, the user does not need to build its custom initramfs, which results in a faster kernel installation.
  • Provides support for the pre-built initramfs systems as it is similar in all installations such as virtual machine (VMs), containers, or cloud instances.
  • Provides support for the x86_64 architecture.
  • Includes the kernel-uki-virt package.
  • Built for virtual machines and cloud instances.
Limitation of UKI because of the reduced flexibility of the boot process
  • When building the UKI, the operating system vendor creates initramfs. As a consequence, the listed and included kernel modules are static. You can use the systemd system and configuration extensions to address this limitation.
  • The kernel command line parameters are static, which limits the use of parameters for different instance sizes or debugging options.

You can use the UKI command line extensions to overcome this limitation.

8.2. Understanding the UKI secure boot process
Copy link

To protect your system against unauthorized boot-time modifications, use the secure boot mechanism with Unified Kernel Image (UKI).

When using UKI with secure boot, the system verifies each component in the boot chain to ensure system integrity and prevent malicious code execution.

Procedure

  1. UEFI Firmware: The boot process starts from the Unified Extensible Firmware Interface (UEFI) firmware. For boot, Red Hat Enterprise Linux (RHEL) UKI requires UEFI firmware, because legacy basic input/output system (BIOS) firmware is not supported.
  2. Shim boot loader: Use the shim boot loader for booting rather than directly booting the UKI from the UEFI firmware. shim includes additional security mechanisms such as Machine Owner Key (MOK) and Secure Boot Advanced Targeting (SBAT).
  3. Signature verification (Secure Boot UEFI mechanism): During boot, shim reads the UKI binary and the secure boot UEFI mechanism verifies the signature of UKI against trusted keys stored in the Secure Boot Allowed Signature Database (db) of the system, the MOK database, and the built-in database of the shim binary. If the signature key is valid, the verification passes.

  4. SBAT verification: Immediately after signature verification, the shim boot loader verifies the SBAT rules at startup.

    During SBAT verification, the system compares generation numbers, for components such as systemd.rhel or linux.rhel, embedded in the UKI by using the .sbat section against values in the shim boot loader. If the generation number for a component in the shim is higher than the generation number in the UKI, the binary gets automatically discarded, even if it was signed by a trusted key.

    Note that the generation number is a version identifier for UEFI applications, such as shim and grub.

  5. Unpacking and Execution: If verification passes, control passes from shim to the systemd-stub code in the UKI to continue the boot process.

  6. systemd-stub add-ons: During execution, systemd-stub unpacks and extracts the contents of the .cmdline section, the plain text kernel command line, and the .initrd section, the temporary root file system, for the boot process.

    Note that systemd-stub reads UKI add-ons and verifies their signatures to safely extend the kernel command line of UKI by appending the .cmdline content from add-ons. systemd-stub reads add-ons from two locations:

    • Global (UKI-independent) add-ons from the /loader/addons/ directory on the Extensible Firmware Interface (EFI) System Partition (ESP).
    • Per-UKI add-ons from the /EFI/Linux/<UKI-name>.extra.d/ directory on the ESP.

  7. Control passes from systemd-stub to the Linux kernel and the operating system boot process continues.

    From this point, secure boot with UKI mechanisms follows the standard kernel boot process.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top