From here to the end: what is left to lock down

Everything so far has been reversible in every way that matters. Files, builds, signatures, even flashing a new bootloader or kernel onto the board — all of it can be undone or redone at will, and I've redone plenty of it more than once along the way. This last post is about the two things in this whole project that genuinely can't be undone, what each one actually buys, and why I'm treating them as a separate decision from everything that came before.

Both of them are what's usually called "burning a fuse" — a one-time, physical change inside the chip itself. Not a metaphor: there are tiny physical connections inside the silicon that get permanently, irreversibly broken, the same one-time idea as an old-fashioned electrical fuse, just etched into the chip instead of sitting in a fuse box. Once blown, there's no undo, ever, on this specific physical chip.

The first fuse: writing down the fingerprint

Back in an earlier post, I generated four signing keys and boiled their public half down into one fixed-size fingerprint — a hash, in the cryptographic sense: a fixed-length number computed from the keys, practically impossible to reverse back into the original keys, and guaranteed (for all practical purposes) to change completely if even one bit of the input changes. Right now, that fingerprint exists only as a file on my computer. Burning this first fuse means writing that exact fingerprint permanently into the chip's own memory.

Here's the part that surprised me the first time I looked into it closely: doing only this changes nothing about how the board actually behaves. Every real test I've run and shown in this series so far — the bootloader check, the kernel check, both the passing and the deliberately-broken versions — ran on a board with this fuse still completely unburned, and the chip still gave completely honest, correct answers every time. Burning this fuse doesn't switch anything on; it just gives the chip a permanent point of comparison to remember, forever, instead of only trusting whatever fingerprint happens to be sitting in a file at boot time. It's the difference between "here's a description of what a valid key looks like" and "here's the one specific key, permanently, no substitutions accepted" — a real, meaningful upgrade in trust, but on its own, still just a stronger description, not yet an enforced rule.

The second fuse: the one that actually locks the door

There's a second, separate fuse elsewhere in the chip whose entire job is different: flipping it is what makes the chip actually refuse to run anything that fails its checks, instead of just reporting the failure and carrying on anyway (the behavior I've relied on throughout this whole series to safely test broken, deliberately-wrong images without ever bricking the board). This is the fuse that turns "an honest reporter" into "an enforcer."

I found out something concrete about this one very recently, in a way that made the distinction unavoidably clear rather than just theoretical: while building toward an automatic pass/fail check as part of the board's normal startup sequence, I discovered that the chip's own built-in "is this signed correctly" check reports success in exactly one more case than "the signature is genuinely valid" — it also reports success whenever this second fuse simply isn't burned yet, no matter what the real answer would have been. Every individual signature check shown throughout this series has been completely real and accurate on its own terms — but a fully automatic "refuse to boot a bad image" safeguard can be built correctly and still can't be proven to actually work, on real hardware, until this specific fuse is burned. That's a genuinely different kind of commitment than the first fuse: it's not just remembering a fingerprint more permanently, it's handing the chip the authority to make its own final call, forever, on this one physical device.

Why I'm not doing either of these on this board, at least not yet

This lab board's entire purpose, since the very first post in this series, has been to be a safe place to learn and break things without real consequences. Everything I've actually needed to prove — that signing genuinely works, that tampering is genuinely caught, that a signed kernel genuinely boots — has been provable without burning anything at all. Both fuses stay a live option for later, not a rejected idea; I'm simply choosing, deliberately, to keep this particular board fully reversible for as long as it's still useful as a sandbox, and to treat "burn something permanently on real hardware" as its own separate, deliberate decision whenever — or if — that day comes, rather than something to slide into as a side effect of finishing something else.

What's actually left, if I ever do decide to burn them

For the record, since I've walked through the how of everything else in this series in real detail: burning either fuse is, mechanically, almost anticlimactic compared to everything that led up to it. The exact numbers to write are already fully computed and printed, sitting right there from the key-generation step back in post 3 — there's no more cryptography left to do, no more building, no more figuring anything out. It's one short command per fuse, run once, by hand, at the board's own console. The actual weight of the decision isn't in the difficulty of the action — it's entirely in the fact that it's the one irreversible step in this whole project, on one specific, physical piece of hardware.

That's the honest, complete state of Track A, this lab unit's own story: a fully proven, fully working, fully reversible secure-boot setup, one deliberate decision away from becoming permanent, whenever that decision actually gets made. From here, this series moves into its second half — carrying everything learned on this disposable lab unit over into the real production system this gateway runs day to day — which is a big enough story to earn its own series.