Generic (UEFI-based) verified boot and update on ARM

This repository aims to provide a reference implementation for generalizing some of the concepts known from the server and desktop world to embedded devices.

It stands on the shoulders of giants - namely Linaro and Siemens - already pushing this approach since a few year. Yet, it tries to further simplify the overall setup and only include the basic verified boot and A/B update scheme here.

Currently, only an integration for qemuarm64 is available. A port on a representative hardware board may follow.

Wait, but why?

• cross-validation from widespread use in the server & desktop world
• rather sophisticated specification
• reduce development & maintenance effort
• cover some gaps, like missing (default) signature for FIT config itself (see u-boot docs)

Also pushed by:

• Embedded Base Boot Requirements EBBR
• Linaro & ARM partnership on SystemReady

Approaches

• Linaro's Trusted Substrate -> TF-A, OP-TEE, u-boot [EFI provider] + systemd-boot [EFI payload, switching BL] + UKI on ESP (vfat) (+ update unclear)
• Siemens -> TF-A, OP-TEE, u-boot [EFI provider] + efibootguard [EFI payload, switching BL] + UKI on ESP (vfat) + swupdate

meta-generic-boot: TF-A, OP-TEE, u-boot [EFI provider, switching BL] + UKIs w/ profiles (no ESP, squashfs or raw partitions possible)

Improvement goals:

• less components to reduce complexity
• full artifact signing
• support for partitioning and no dependency on ESP
• robust filesystems support
• sophisticated boot counting possible (in comparision to systemd-boot's file-rename-based approach)

Readings:

• UEFI-based secure boot on ARM - Siemens @ ELC 2022
• isar CIP Core implementation GitHub
• Linaro blog: UEFI secure boot in u-boot
• Introduction to Linaro's TrustedSubstrate (2025)

Considerations

General preconditions for UEFI on ARM

• ARM TrustZone for extended firmware support
• eFuses and/or eMMC with Replay Protected Memory Blocks (RPMB) for storing the keyring

Splitting OS and bootloader updates

Established approaches on embedded Linux devices often use a common path for both updating the Linux side of the system as well as the bootloader (see RAUC's capabilities on doing that, for example). In contrast to this, the TF-A architecture and UEFI specification separate the two by defining capsule updates for updating the firmware (at least the extended firmware scope or FIP [Firmware Interface Package]). This would then also include the bootloader. An advantage of this is, again, that implementations must follow a clear specification, while some aspects like the requirement for a FAT-based EFI System Partition are potential downsides - especially in the embedded context.

Alternatives to using u-boot as switching bootloader

Reasoning according to Siemens:

• Low trust in its (UEFI-related) implementation
• Missing support for (secure) storage of the switching flag (i.e. BootOrder and BootNext)
• Early exit from watchdog

Also see this talk.

Core technologies

• Trusted Firmware for Cortex-A (docs for QEMU, blog)
• meta-arm for TF-A, EDK2, ...
• UKIs with multiple profiles (ukify docs)
• u-boot as EFI provider (docs)
• RAUC integration docs
• QEMU ARM virt machine (doc)

Challenges and limitations

Secret handling

Common approaches: efuses, OP-TEE w/ RPMB eMMC (yet, this is still accessible from userspace), burned into binary

Issues:

• No guaranteed protection against access from kernel / userspace
• In QEMU: missing emulation support

meta-generic-boot: Limited due to secrets built-in to u-boot binary, requiring firmware update for key rotation.

Readings:

• Blog by Linaro: Protected UEFI variables with u-boot
• Patchset for QEMU by Jan Kriska for RPMB support

Runtime, authenticated variables

Current status: no SetVariableRT in u-boot (barebox maybe?)

Readings:

• Overview by Ilias at Linux Plumbers 2023 (Session, PDF)

meta-generic-boot: Limited by a workaround loading variables from an ESP in separate disk and manually persisting it by copying over changes only written in RAM (also comes with a different u-boot config). Also no further means to protect against rollback are implemented yet.

Gapless watchdog configuration

Current status: Potential gap between ExitBootServices & Kernel watchdog activation

U-Boot has support for serving the hardware watchdog until ExitBootServices() (according to the UEFI spec).

Readings:

• Discussions about the u-boot implementation in the trusted-firmware.org mailinglist

Loose ends

• Fine-tune watchdog configuration to avoid a gap?
• Build testenv Docker image including changes in QemuDriver
• Automatically provide secrets for update bundle signing
• Upstream patches in meta-arm and labgrid
• Upstream extensions for uki.bbclass
• Take over patchset on QEMU for RPMB eMMC emulation and remove workaround
• Implement capsule updates for bootloader updates

General observations

• Many of the involved open source projects lack beginner documentation
• Implementations by Linaro and Siemens have a lot more features than the presented approach (which makes it hard to understand at times)
• Lots of building blocks already in upstream layers - though quality & maintenance needs to be monitored

Recent advances in alternative approaches

• Barebox will (soon) support direct FIT image verification - further reducing the attack surface for altered content in the OS images (see this talk by A. Fatoum)

Further readings

• swtpm & QEMU configuration: Linaro blog, ejaaskel.dev