A verified boot chain for embedded Linux has five links: an immutable first stage in hardware, a signed bootloader, a signed kernel image, a verified root filesystem, and an update scheme that can fall back and refuse old versions. Each link checks the next. Gaps appear between the links, not inside them.
Link one: the hardware root
Everything starts with something you must believe without proof. ETSI EN 303 645 describes a hardware root of trust as the source of cryptographic trust from which other components derive trust, and as resistant to physical and logical tampering. In practice it is immutable boot code and a stored key or key hash. The exact mechanism comes from your chip vendor.
Link two: bootloader to kernel
U-Boot's documentation describes verifying signed FIT images against a public key in its control device tree. The key does not need to be secret, but it must not be changeable. Chain keys across stages if you can, using a different key for each.
Link three: root filesystem
The kernel's dm-verity target checks a read-only block device against a hash tree, with the root hash supplied at setup. That root hash must be trusted, so deliver it inside the signed image that link two verified. Choose what happens on a bad block, and avoid the options that merely log corruption in production.
Link four: updates with a fallback
A/B slots, as Android documents them, let the device write the update to the inactive slot, boot it, and fall back if it fails to boot. Mark a slot good only after a post boot check passes, such as a dm-verity integrity check.
Link five: rollback protection
MCUboot, though aimed at microcontrollers, shows the concept clearly: a security counter in the signed image compared against a trusted counter on the device. Whatever bootloader you use, plan an equivalent. Without it, an attacker can install an older, signed image.
Where the gaps are
- Key handoff. The key each stage trusts must come from the stage before it, not from a writable file.
- Unverified writable areas. Configuration or scripts on a writable partition can change behaviour even when the root filesystem is verified.
- Debug access. A serial console that bypasses the chain defeats it. ETSI 5.6-4 says physically accessible debug interfaces shall be disabled in software.
- Recovery mode. If recovery accepts unsigned images, the chain has a side door.
- Signing key custody. The most secure device is exposed if the signing key is on a shared build server.
A test list
Boot with a modified bootloader, kernel, root filesystem and update package in turn. Try an old signed image. Try the debug port. Each one should fail in the way you designed. Write down the result, since it becomes evidence for customers and auditors.
Quick check
Is dm-verity enough on its own?
No. It verifies a block device against a root hash, and that root hash must itself be trusted, usually via the signed boot image.
Does A/B replace rollback protection?
No. A/B gives a fallback after a failed update. Rollback protection stops an old vulnerable image from being installed.
Where Safeguard fits
Safeguard covers the software supply chain side of this work: SBOM and dependency scanning, policies and gates, and compliance and evidence automation. It does not replace hardware security features. A free scan is available at gold.safeguard.sh/scan.
Sources
- ETSI EN 303 645 V2.1.1 (2020-06)
- U-Boot verified boot with FIT images
- dm-verity, Linux kernel documentation
- A/B (seamless) system updates, Android Open Source Project
- MCUboot design
Last reviewed: 19 October 2026.
