Build Once, Trust Always: Single-Image Secure Boot with barebox

Secure-boot projects often end up with a zoo of nearly-identical bootloader images for development, factory, and field use with each variant adding more risk. This showcase illustrates how to avoid this entirely: one bootloader image that adapts securely to each lifecycle stage using fuse-based state transitions, device-bound unlock tokens, and policy-driven access control. With barebox and OP-TEE, we’ll show how these mechanisms enforce secure operation while still allowing controlled debugging and recovery, without ever maintaining multiple images.

Netboot without throwing a FIT

For years, Ahmad’s ideal has been simple: unpack a rootfs on a server, mount it over NFS (or usb9pfs), boot directly into it, and everything just works™. But as secure boot becomes the default on many embedded systems, squeezing in a network-booted kernel is getting harder and often falls outside the supported boot flow entirely. Fortunately, some recent improvements in the kernel build system pave the way for a far less invasive netboot setup. This talk gives a quick tour of the key pieces:

• The image.fit target for arm64 introduced in v6.10
• The modules-cpio-pkg target introduced in v6.19
• Initramfs that bind mounts its modules over the rootfs
• Optional concatenation of multiple initramfs in the bootloader

In ten minutes, you’ll see how these changes raise the netboot FITness of Linux, so you can keep printk-debugging to your heart’s content.

Tamper-resistant factory data from the bootloader

Secure-boot chains in embedded systems have largely converged on common building blocks like FIT, dm-verity or UKIs. The bootloader is anchored in hardware trust, then verifies an operating system image, and the chain continues, eventually covering the application. But there is a gap when it comes to adding unit-specific bits of information, such as per-device configuration, hardware calibration, or MAC addresses needed early in boot.

In this segment, I present the TLV framework recently added to the barebox bootloader, to which I contributed signature support. It allows device-specific key-value pairs to become part of the secure-boot chain from early on, providing the system with authenticated, replay-protected per-unit data.

This short presentation discusses - factory data and its relevance to a secure-boot chain - the barebox implementation using a signed Tag-Length-Value format - when and how to prevent interchange of TLV blobs across units - integration of the new feature.