Firmware you can flash: why open hardware matters

Firmware you can flash is firmware the owner of a device can replace, with software they built or chose, without breaking the security that protects them. That is the short definition of owner-controlled firmware, and it is the part of open hardware we care about most. Open schematics are nice. Being able to decide what runs on the thing in your hand is what keeps a device useful after the company that made it has moved on.

We designed our Humanly Slate concept around this idea, with a bootloader that only trusts a key the owner enrolled. This post steps back from that one device and looks at how the pieces work in general, where the real risks are and why we think it matters more every year.

What happens when a device boots

Almost every modern device starts the same way, whether it is a phone, a router, a laptop or an e-reader. The details differ, and the names change between platforms, but the shape is a chain.

1. Boot ROM. A small piece of code burned into the chip at the factory. It cannot be changed. Its job is to find the next stage, load it and, on a secured device, check its signature against a key or key hash that is also fixed in the chip.
2. Bootloader. Often in more than one stage. It sets up memory and storage, decides which operating system image to start and checks that image's signature before handing over.
3. Kernel and operating system. Once running, the operating system can keep checking what it loads. On Android, for example, verified boot extends to the system partitions, so a modified system file is detected when it is read.
4. User data. Usually encrypted with keys that are only released if the chain above booted as expected.

This is called a chain of trust. Each link is trusted because the link before it checked it. The very first link, the boot ROM, is trusted because it cannot be changed. Everything depends on it being small and correct.

The key question for owners is simple. Whose keys does the bootloader accept? On most consumer devices the answer is: only the manufacturer's. That is good for security against strangers, and it also means the owner cannot run anything else.

Verified boot with the owner's key

There is a middle path, and it already exists on some hardware. The bootloader can hold a slot for a user-supplied key. When the owner enrolls a key, the bootloader will verify and boot images signed by it, and it will say so clearly at start-up.

Some Android phones support this. You unlock the bootloader, flash an operating system signed with a different key, enroll that key and lock the bootloader again. From then on, verified boot protects the custom system just as it protected the stock one, and the phone shows a notice at boot that it is running a different operating system. Several security-focused Android distributions depend on exactly this feature, because without relocking, an unlocked phone is much easier to tamper with.

PCs have a version of the same idea. UEFI Secure Boot lets the owner enroll their own platform and signing keys, remove the defaults and sign their own boot loaders and kernels. It is fiddly, and firmware menus vary widely between vendors, but the capability is there on a lot of machines.

The wipe is the important detail. On a well-designed device, changing the lock state erases user data. That sounds harsh, and it is the point. Someone who picks up your phone for ten minutes can unlock the bootloader and flash something, but they cannot do it without destroying the data they were after, and you will notice when your phone greets you as new.

Bricks and the way back

The fear that stops most people from flashing firmware is bricking: ending up with a device that does nothing. It is worth separating the two kinds.

A soft brick is a device where the operating system fails to start, but the bootloader or a recovery environment still works. You can reflash and carry on. This is by far the most common outcome of a bad flash, and on a device with a good recovery path it is a minor annoyance.

A hard brick is a device where even the bootloader is gone or damaged, so nothing on the device can help. Many chips still have a way back at this point, because the boot ROM usually includes a download mode that accepts an image over USB. Phones, microcontrollers and many single-board computers have something like this. The catch is that the tools and signed images for it are often not public.

Good designs make bricking hard in the first place:

• A/B slots. The device keeps two copies of the system. Updates go to the inactive slot, and the device only switches once the new one boots cleanly. If it fails a few times, it falls back to the old slot.
• A protected bootloader. The first stage is write-protected or read-only, so a bad flash of the operating system cannot damage it.
• A physical recovery mode. A key combination at power-on that always reaches a known, minimal state, independent of whatever is installed.
• Documented download mode. The boot ROM recovery path is described, and the tools to use it are published.

If a device has all four, flashing it is about as risky as reinstalling an operating system on a laptop.

The security trade-offs

We would be misleading you if we said open firmware had no cost. It does, and the costs are specific.

Physical access gets more interesting. On a device that only boots the maker's code, an attacker with the device in hand has fewer options. On one that accepts owner keys, the enrollment step itself becomes a target. That is why enrollment should need physical presence, such as a button combination, and should wipe data.

You become the signing authority. If you sign your own images, your private key matters. Lose it and you cannot update. Leak it and someone else can sign firmware your device will trust. A hardware security key helps. So does a documented, data-wiping reset path.

Rollback. Verified boot alone does not stop someone from flashing an older signed image with a known vulnerability. Anti-rollback counters, which record the lowest version the device will accept, fix that. They also stop you from going back to a version you liked. It is a real tension, and the answer depends on what the device is for.

Updates. A community build may get security fixes later than the maker's, or not at all, especially for closed parts like modem firmware and GPU drivers, which usually stay as binary blobs even on open platforms. Being able to flash your own software does not mean every layer is open.

We think these costs are worth paying when they are designed for, and dangerous when they are an afterthought. A device where unlocking is an undocumented exploit is worse for everyone than one where it is a supported, visible, data-wiping switch.

Why it matters for longevity

Devices tend to outlive the software support behind them. The screen still works, the battery can be replaced (see The repairable device), but the maker has stopped shipping updates, the cloud service it depended on has been switched off, or a new file format arrives that the old firmware cannot open.

Community firmware is how a lot of hardware stays useful after that point. OpenWrt keeps old routers running with current security fixes. Custom Android builds extend phones by years. Rockbox gave a long second life to music players that their makers had stopped caring about. Coreboot replaces proprietary boot firmware on some laptops and Chromebooks. None of these projects would exist if the hardware had been completely locked, and most of them started because someone reverse engineered a device that was never meant to be opened.

Documentation is what turns that from heroics into maintenance. A published memory map, a described boot process, the pinout of a debug header and the recovery procedure save a volunteer months of work. For a maker, writing them down costs very little compared to building the device.

What we would ask of any device

This is the short list we used when drawing the Slate, and it is what we would look for when buying almost anything with firmware in it.

• An official, documented way to unlock the bootloader, which wipes data and shows a clear warning at boot.
• Support for enrolling an owner key and relocking, so custom software can still be verified.
• A recovery mode that cannot be overwritten, reachable with buttons alone.
• Published documentation for the boot process and recovery tools.
• A commitment to leave the unlock path available after official support ends.

That last line costs a manufacturer almost nothing and is the one that most often goes missing. A server switched off in a data centre can turn a working device into a paperweight. An unlock path left in place means the device goes to whoever wants to keep it running.