Module 1
Real Boot Chain: ROM -> Bootloader -> Kernel -> Rootfs
This module replaces conceptual secure boot diagrams with the actual boot sequence used in embedded Linux products.
Read 4 minAvg understanding 9 min
Learning objectives
- Map the production trust chain from immutable ROM to userspace
- Differentiate first-stage and second-stage bootloader responsibilities
- Identify exactly where verification must continue beyond kernel load
Why "PowerPoint secure boot" fails in products
Most diagrams show one lock icon on "bootloader" and stop there. In real devices, trust must continue across multiple boundaries:
- SoC immutable ROM loads first mutable stage
- First-stage bootloader initializes memory/clock and authenticates next stage
- Second-stage bootloader (often U-Boot) verifies kernel + DTB + optional initramfs
- OS startup enforces rootfs trust model and runtime policy
If any stage skips verification, the chain is broken.
Real chain of trust sequence
1) Immutable ROM and hardware root of trust
- ROM code is your first verifier.
- Public key hash or key digest is anchored in OTP/eFuses or immutable storage.
- ROM accepts only signed first-stage image.
2) First-stage bootloader (FSBL / BL1)
- Brings up enough hardware to load second-stage.
- Should verify BL2/U-Boot using key material allowed by ROM policy.
- Often includes anti-rollback checks using version counters.
3) Second-stage bootloader (U-Boot)
U-Boot is frequently where product teams do or break security:
- Verify FIT image signatures.
- Verify kernel, DTB, and optional ramdisk.
- Pass security state to kernel (
bootargs, device-tree flags, measured values).
4) Kernel and rootfs trust
Secure boot does not end at kernel handoff:
- Kernel image is verified at boot stage.
- DTB must also be verified (common miss).
- Rootfs should be immutable or integrity-protected (
dm-verity, signed A/B artifacts).
Practical engineering checklist
- What immutable key anchor exists in hardware?
- Which stage verifies each next artifact?
- Where is version checked for anti-rollback?
- Is DTB explicitly verified?
- How is rootfs integrity enforced after kernel starts?
Practical takeaway
Treat secure boot as a continuous verification pipeline, not a single bootloader feature toggle.
Misconception to correct
"If ROM verifies bootloader, we are secure."
Not true. You also need verification continuity through kernel, DTB, and rootfs/update flow.
Previous lesson
You are at the first lesson.
Next lesson
Where Attacks Actually Happen in Shipping Devices