Context
A device you cannot update is a security liability. A device you can update badly is worse — a single flawed release reaching an entire fleet is one of the few failure modes that can end a product line.
This reference architecture treats updates and the chain of trust as a single design problem, because they are.
Requirements that drive everything else
- Power loss is normal, not exceptional. The update must be atomic with respect to power failure at every instant, including the microsecond during the bootloader’s switch of the active slot.
- A bad image must not be permanent. The device must detect that a new image is unhealthy and return to the previous one without human intervention.
- Only authorised images may run. Every stage validates the next before transferring control.
- Downgrade is an attack. An attacker who can replay an old, signed but vulnerable image has defeated the update mechanism entirely.
Architecture
A/B partitions with an atomic switch. Two complete root filesystem slots. The inactive slot is written and verified in full, then a single bootloader environment variable — written atomically with a redundant, checksummed copy — selects it. Power loss before the write leaves the old slot active; power loss after leaves the new one. There is no intermediate state in which neither is valid.
Boot-count watchdog. The bootloader increments a persistent boot counter before handing off. The application clears it only after passing a health check that exercises real functionality — network reachable, peripherals responding, services up — not merely “the kernel booted”. If the counter exceeds its limit, the bootloader reverts to the previous slot on its own.
Chain of trust. The immutable boot ROM verifies the first-stage loader; that verifies U-Boot; U-Boot verifies the kernel and device tree; dm-verity covers the root filesystem block by block at runtime, so corruption is detected on access rather than only at install. Keys live in a TPM or in the SoC’s secure element, never in the filesystem.
Anti-rollback. A monotonic version counter in one-time-programmable fuses or TPM NV storage. Images below the stored version are refused regardless of a valid signature.
Signed manifests. The device validates the manifest — version, hashes, target hardware revision, compatibility constraints — before writing a single byte to flash. Hardware-revision gating prevents an image built for one board variant reaching another.
Fleet-side design
The device is only half the system:
- Staged rollout. Internal devices, then a small canary cohort, then progressive expansion. The stage gate is automatic and based on measured device health, not on a calendar.
- Automatic halt. If the failure rate in the current cohort exceeds threshold, the rollout stops itself and pages a human. This is the control that turns a bad release from a fleet-wide incident into a contained one.
- Bandwidth realism. Delta updates where the transport is metered or slow, resumable transfers, and randomised scheduling so a fleet does not synchronise into a thundering herd against the update service.
- Observable state. Every device reports its running version, slot, boot count and last update result. “Which firmware is actually deployed right now?” must be answerable in seconds.
Verification
The test plan is mostly about deliberate cruelty: power interruption injected at randomised points throughout the write and switch sequence, corrupted and truncated images, valid signatures over the wrong hardware revision, replayed old images, and a full soak across a representative hardware sample — including the oldest board revision still in the field, which is invariably the one that breaks.
What this demonstrates
Update systems fail in the gaps between components: the bootloader assumes the application will clear the counter, the application assumes the manifest was checked, the server assumes the device will report failure. This architecture closes those gaps explicitly, and the verification plan attacks each one.