Nearly 17 years ago, barebox forked from Das U-Boot with a simple question: Why can't bootloader developers have nice things? "Nice" meant feeling like the Linux kernel and that included portability and being free of per-board assembly.

The catch: the kernel is nice because the bootloader does the unpleasant work of turning a reset vector into a place where portable code may run. Undeterred, barebox's very earliest code was written in C anyway, fueled by a heavy dose of GNU extensions, macro magic, linker-script choreography, and, in hindsight, behavior neither the C standard nor GCC ever promised. GCC was charitable — until its optimizer wasn't.

This talk narrates how barebox came to confront its past: sometimes by writing better C, sometimes by admitting C wasn't the right language (ARMv8 MMU disablement: please don't).
Some cleverness has Linux ancestry; much was grown locally.

Topics span build time (hundreds of per-board entry points sharing common relocatable objects), early init (C relocation code that fixes up its own relocations live), and runtime challenges (legitimate uses for accessing page zero; pointer-dereference woes across caches, MMIO, and hardware virtualization) and nifty features (green threads; pressing KASAN into tracking DMA-buffer ownership).

You'll leave entertained (or slightly unnerved?), but with a feel for which problems belong in C and where we've exorcised nasal demons firsthand.

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.

In this lightning talk, I present barebox's Security Policy support, which facilitates adapting securely to each lifecycle stage and how the state transition can be controlled via eFuses, device-bound unlock tokens or hardware-rooted storage.