Implementing UEFI-based Secure Boot + OTA Update for Embedded ARM Devices
Jan Kiszka & Christian Storm, Siemens AG [Open Source Summit EU 2022]

Nowadays, field updates are unavoidable but must also be secure, unattended, and robust (i.e. atomic + automatic rollback). On x86 you boot UEFI which verifies the signature of the bootloader and loads it. The bootloader takes care of A/B switching (UEFI can do that itself, but do you trust the firmware?); it also starts a wachtdog. The bootloader loads kernel+commandline+initrd image after verifiying it. The kernel verifies and unlocks the (encrypted) rootfs. The platform key for dmcrypt comes from TPM.

ARM64 typically uses U-Boot + TF-A, but there is still custom engineering needed. There is also no standard for getting the key. However, ARM64 is also evolving to UEFI. There is even project to use U-Boot as a UEFI provider. With that, the same boot/update/verification flow can be used as on x86. For the secrets, there is OP-TEE.

There are two UEFI providers for non-x86 now: EDK II (which is also used on many x86 firmware). But not many SoC vendors support EDK II, so also not many drivers for SoCs in upstream. Conversely, U-Boot is the de-facto standard, and it does have fairly advanced UEFI support already, but it’s not used very much. It’s even default on - you can often load grub from U-Boot! However, for secure boot, you need to establish chain of trust. There are two ways: hardcode the signing public keys in the U-Boot binary, or store the keys in UEFI variables.

U-Boot also needs to be hardened: lock console, limit to UEFI boot, turn off unused features (e.g. filesystems), make environment readonly (so you can’t use a bootscript to bypass verified boot).

UEFI payload is efibootguard (which takes care of A/B etc.), can be reused from x86. However, it uses a unified kernel image which includes DTB, but then only a single DTB can be supported. So they implemented a unified kernel image generator that uses a stub loader in the beginning that allows to support multiple DTB images.

To find the rootfs, efibootguard mounts all candidate rootfses and checks the IMAGE_UUID in /ets/os-release and matches this with the IMAGE_UUID given on the root= commandline. Rootfs is a squashfs which is protected with dm-verity. dm-verity’s metadata ends with a root hash which is given on the kernel commandline, and this root hash can actually be used to find the correct rootfs.

These concepts are integrated in isar-cip-core (a Debian-based meta-distro maintained by CIP), but from there can be easily ported to other build systems.

The dm-crypt part of the story is not published yet.