VolumeConfig tpm.pcrs option - see the TPM encryption options for details.
PCR Binding Options
- Default: PCR 7 (SecureBoot state) + PCR 11 signed policy (UKI measurements and boot phases)
- Configurable: Any combination of PCRs can be specified
- No PCRs: Can be disabled by passing an empty list, relying solely on PCR 11 signed policy
- Backward compatibility: Existing installations continue to use their original PCR binding
- Frequent Updates: PCR 7 covers the SecureBoot policy, particularly the “dbx” denylist of revoked certificates
- Automatic Updates: Tools like
fwupdnow automatically update the SecureBoot database, causing PCR 7 to change frequently - Brittleness: Literal PCR 7 policies break when firmware or SecureBoot databases are updated, even without policy changes
Note: SecureBoot is not supported on x86 platforms in BIOS mode.
SecureBoot Flow
The SecureBoot process follows a strict verification chain from UEFI firmware to the final operating system: The implementation is using systemd-boot as a boot menu implementation, while the Talos kernel, initramfs and cmdline arguments are combined into the Unified Kernel Image (UKI) format. UEFI firmware loads thesystemd-boot bootloader, which then loads the UKI image.
Both systemd-boot and Talos UKI image are signed with the key, which is enrolled into the UEFI firmware.
As Talos Linux is fully contained in the UKI image, the full operating system is verified and booted by the UEFI firmware.
Note: There is no support at the moment to upgrade non-UKI (GRUB-based) Talos installation to use UKI/SecureBoot, so a fresh installation is required.
SecureBoot with Sidero Labs Images
Sidero Labs provides Talos images signed with the Sidero Labs SecureBoot key via Image Factory.
Note: The SecureBoot images are available for Talos releases starting from v1.5.0.
The easiest way to get started with SecureBoot is to download the ISO, and
boot it on a UEFI-enabled system which has SecureBoot enabled in setup mode.
The ISO bootloader will enroll the keys in the UEFI firmware, and boot the Talos Linux in SecureBoot mode.
The install should performed using SecureBoot installer (put it Talos machine configuration): factory.talos.dev/installer-secureboot/376567988ad370138ad8b2698212367b8edcb69b5fd68c80be1f2ec7d603b4ba:${release_v1_12}.
Note: SecureBoot images can also be generated with custom keys.
Booting Talos Linux in SecureBoot Mode
In this guide we will use the ISO image to boot Talos Linux in SecureBoot mode, followed by submitting machine configuration to the machine in maintenance mode. We will use one the ways to generate and submit machine configuration to the node, please refer to the Production Notes for the full guide. First, make sure SecureBoot is enabled in the UEFI firmware. For the first boot, the UEFI firmware should be in the setup mode, so that the keys can be enrolled into the UEFI firmware automatically. If the UEFI firmware does not support automatic enrollment, you may need to hit Esc to force the boot menu to appear, and select theEnroll Secure Boot keys: auto option.
Note: There are other ways to enroll the keys into the UEFI firmware, but this is out of scope of this guide.Once Talos is running in maintenance mode, verify that secure boot is enabled:
installer-secureboot container image, and applying the patch to enable TPM-based disk encryption (requires TPM 2.0):
Upgrading Talos Linux
Any change to the boot asset (kernel, initramfs, kernel command line) requires the UKI to be regenerated and the installer image to be rebuilt. Follow the steps above to generate new installer image updating the boot assets: use new Talos version, add a system extension, or modify the kernel command line. Once the newinstaller image is pushed to the registry, upgrade the node using the new installer image.
It is important to preserve the UKI signing key and the PCR signing key, otherwise the node will not be able to boot with the new UKI and unlock the encrypted partitions.
Disk Encryption with TPM
When encrypting the disk partition for the first time, Talos Linux generates a random disk encryption key and seals (encrypts) it with the TPM device. The TPM unlock policy is configured to trust the expected policy signed by the PCR signing key. This way TPM unlocking doesn’t depend on the exact PCR measurements, but rather on the expected policy signed by the PCR signing key and the configured PCR states (by default includes PCR 7 for SecureBoot status and the list of enrolled keys, plus PCR 11 for boot integrity).PCR Measurements in Detail
The Unified Kernel Image (UKI) boot process involves several measurement stages that record cryptographic hashes into TPM Platform Configuration Registers (PCRs):systemd-stub UKI Measurements (PCR 11)
According to the UAPI Unified Kernel Image specification and systemd-stub documentation, systemd-stub measures the following UKI sections into PCR 11:.linuxsection - The Linux kernel binary (PE section containing the ELF kernel image, required).osrelsection - OS release information (PE section with/etc/os-releasecontents).cmdlinesection - The kernel command line arguments (PE section with embedded cmdline).initrdsection - The initial ramdisk image (PE section containing initramfs).ucodesection - Microcode initrd (PE section with CPU microcode updates, uncompressed).splashsection - Boot splash image (PE section with Windows BMP format image).dtbsection - Device tree blob (PE section with compiled binary DeviceTree).dtbautosections - Automatic DeviceTree selection (zero or more PE sections, first match used).efifwsections - Firmware images (zero or more PE sections for firmware blobs).hwidssections - Hardware ID matching (zero or more PE sections with SMBIOS-based hardware IDs).unamesection - Kernel version information (PE section withuname -routput).sbatsection - SBAT revocation metadata (PE section for Secure Boot Advanced Targeting).pcrpkeysection - PCR signature public key (PE section with PEM format public key)
.pcrsig section is not measured into any PCR, as it contains the signatures for the measurement results themselves.
systemd-boot Measurements
The systemd-boot bootloader can optionally measure loaded boot entries and configuration, though this is typically not used in Talos UKI scenarios since the UKI can be loaded directly.Talos Boot Phase Measurements (PCR 11)
In addition to the UKI section measurements, Talos extends PCR 11 with its own boot phases to track the operating system initialization:enter-initrd- Extended when Talos initrd startsleave-initrd- Extended just before switching to the main system (machined)enter-machined- Extended before starting the main Talos supervisorstart-the-world- Extended after disk decryption and before starting all system services
start-the-world phase is measured into PCR 11 after the encrypted disk has been unlocked. This ensures that user services and workloads cannot decrypt the disk themselves, as any attempt to access TPM-sealed keys will fail due to the changed PCR 11 value.
TPM Unlock Policy
The TPM sealed disk encryption key can only be unsealed when the system reaches theenter-machined phase. This is the critical security boundary - the disk can only be decrypted if:
- The UKI sections (kernel, initrd, cmdline, etc.) match the expected measurements (PCR 11)
- The boot reached the legitimate
enter-machinedphase (PCR 11) - The configured PCR states match (by default, includes PCR 7 for SecureBoot state)
Configurable PCR Binding (Default: PCR 7)
By default, new Talos installations and upgrades maintain binding to PCR 7, which includes:- SecureBoot enabled/disabled state
- Enrolled SecureBoot keys (PK, KEK, db)
- Any changes to the UEFI SecureBoot configuration
VolumeConfig tpm.pcrs option - see the TPM encryption options for details.
When the UKI image is generated, the UKI is measured and expected measurements are combined into TPM unlock policy and signed with the PCR signing key.
During the boot process, systemd-stub component of the UKI performs measurements of the UKI sections into the TPM device.
Talos Linux during the boot appends to the PCR register the measurements of the boot phases, and once the boot reaches the point of mounting the encrypted disk partition,
the expected signed policy from the UKI is matched against measured values to unlock the TPM, and TPM unseals the disk encryption key which is then used to unlock the disk partition.
TPM PCR Measurement Chain
The Trusted Platform Module (TPM) maintains Platform Configuration Registers (PCRs) that record measurements of boot components: During the upgrade, as long as the new UKI contains PCR policy signed with the same PCR signing key, and the configured PCR states have not changed, the disk partition will be unlocked successfully. By default, disk encryption is tied to the state of PCR 7 (SecureBoot state) in addition to PCR 11 (boot integrity), so that it unlocks only if both the boot chain is valid and SecureBoot is enabled with the expected key set. However, the PCR binding is fully configurable via theVolumeConfig tpm.pcrs option - see the TPM encryption options for details.
Other Boot Options
Unified Kernel Image (UKI) is a UEFI-bootable image which can be booted directly from the UEFI firmware skipping thesystemd-boot bootloader.
In network boot mode, the UKI can be used directly as well, as it contains the full set of boot assets required to boot Talos Linux.
When SecureBoot is enabled, the UKI image ignores any kernel command line arguments passed to it, but rather uses the kernel command line arguments embedded into the UKI image itself.
If kernel command line arguments need to be changed, the UKI image needs to be rebuilt with the new kernel command line arguments.
SecureBoot with Custom Keys
Generating the Keys
Talos requires two set of keys to be used for the SecureBoot process:- SecureBoot key is used to sign the boot assets and it is enrolled into the UEFI firmware.
- PCR Signing Key is used to sign the TPM policy, which is used to seal the disk encryption key.
_out/uki-signing-* files as input:
Note : UEFI decides what Secure Boot trusts. By default,talosctl gen secureboot ...generates a self-signed UKI signing certificate andPK.auth/KEK.auth/db.authfor enrollment. You can also generate your own version of these files which uses other signing keys and certificate authorities specific to your environment.