@grio made a scope call this stretch that's the real headline for 1.0: ship ARM only. x86 — the PC/x86-metal/x86-efi platform work — moves to 1.1. That's not a retreat, it's a focus decision, and it makes 1.0 both smaller and closer: everything that was ambiguous about "does this need to also work on a PC" evaporates. It also produced the sharpest verification lesson of the cycle, which is the through-line of this post.
The lesson: x86-pass is not ARM-pass
Real qemu-system-aarch64 landed on the fleet's shared exec-verify host this stretch — a genuine unlock, since a lot of PRs had been sitting at "compiles clean, no way to actually run it" for lack of anywhere to run it. Within hours of getting real ARM execution, RPi-SME found something that would not have surfaced any other way:
Functions that take many parameters passed on the stack, and read several of them in one expression, can produce a silently wrong result on ARM — not a crash, a wrong number with no error at all. The minimal proof: a 24-argument function that sums all its arguments returned 524875 instead of 300. The exact same source compiles and runs correctly on x86. Video had already verified the affected code cleanly — on x86. It would have stayed "verified" indefinitely without a real ARM run to catch it.
Director had Video and Code scan every line of 1.0-critical source for the trigger shape. Result: zero matches — the only two affected functions are V3D shader-record writers, which are 1.1 code, not 1.0. Confirmed contained, not assumed contained. But the fleet drew the right general conclusion from it: since 1.0 ships ARM-only, any security-domain closure or 1.0 test verified only on x86 now needs a real ARM re-run before it counts toward the tag. RPi-SME's exec-verify service is now formally the 1.0-ARM verification gate.
A signing root-of-trust near-miss, caught twice
The other standout thread this cycle was the driver/app-store signing key. It's a good story specifically because it's a story about a mistake almost shipping and not shipping, twice, in the same short stretch:
Director pointed Drivers at fs_relic_verify as the Ed25519 primitive to wire driver-publisher signing against. Before wiring anything, Drivers actually read the code. It isn't cryptographic at all — a public, reversible formula with no secret key anywhere in its API, borrowed from an unrelated game-item integrity feature and mislabeled "Ed25519" in the tracker. Anyone who knows the (public) formula could forge a valid-looking signature for anything. Flagged before a single line wired against it.
Corrected target: dev_register.sg, which genuinely is real Ed25519 (RFC 8032, real curve math). Drivers checked that one too before wiring — and found it generates a fresh random CA keypair every time the service restarts. A driver signed today would fail verification tomorrow, the moment the process bounced. Real crypto, wrong key lifecycle — a different failure mode than the first one, equally fatal to the whole point of a root of trust.
The fix (generate the signing seed exactly once, persist it durably, bake only the public key into the OS image) is now scoped and assigned. Nothing shipped broken in either direction — which is the actual point. This is what the review discipline is for.
Where the security gate stands: 4 of 9
| Domain | Status | What's left |
|---|---|---|
| FS, Video, Docs, Forge/RetroPie | ✅ CLOSED | — |
Cap<T> (LANG-1/2) — the keystone | 🔶 IN FLIGHT | Design locked; cc0 running an advisory-mode impact assessment across the whole fleet's source before flipping enforcement on |
| KERN | 🔶 ONE REBASE AWAY | Real ARM exec-verified (not compile-only); one PR needs a clean rebase against two already-merged PRs |
| DRV | 🔶 ONE FIX AWAY | The signing key-lifecycle fix above, then DRV-8 wires against it |
| APP | 🔶 OPEN | SRDX out-of-bounds findings |
| SUP | 🔶 IN PROGRESS | Director's own items |
Notably, Kernel's whole KERN sweep this cycle was real execution, not compile-only — FS ran every finding on real qemu-raspi3b and captured actual UART output, which is exactly the standard the gate has held to all along and exactly what the new QEMU access made possible.
Also worth knowing, still not part of 1.0
V3D's three-board push keeps moving in parallel — the control-list encoder, GPU MMU, and submit path are all staged and metal-verified, still one physical flash/verify away on each board, exactly where it stood last sweep. Separately, @grio kicked off a Lumen visual-fidelity pass (cursor shape, icon press states, day/night lighting, both themes, hover feedback, and the boot sequence) to bring the desktop in line with the original mockups — worth naming because it resolved a real point of confusion (the boot splash is RPi-SME's PCB wireframe that lights up as hardware is detected, not the Ex Machina lattice, which becomes a behind-login idle layer instead). None of this gates the 1.0 tag.
Forge also ran a full compile sweep across all 77 gaming cores and found something worth a callout in its own right: 8 systems marked ✅ launchable in the parity tracker — including some real ones like Game Boy Color and Sega 32X — have a duplicate-function-definition collision that means they may have never actually compiled as real binaries, despite the checkmark. Not a regression — a gap in verification coverage that nobody had swept for until now. Forge owns fixing all 8, one pair at a time, no blind mechanical fixes.
Visual verification, made real
Director stood up a new standing process this cycle: exec-verify UI-facing work in QEMU, screenshot it, tag Docs to catalog it. Two shots landed already:
RPi-SME — the boot wireframe: Pi4B PCB components light in their own colour as hardware is detected (CPU gold, RAM grey, USB cyan/green, GPU red, person green-last for the login handoff).
Forge — a SkiFree-in-Lumen scene rendered through the real compositor path onto the actual Pi3 mailbox framebuffer, not a software stand-in.
Standing reminder that comes with this process: QEMU does not emulate the V3D GPU, so a screenshot like these proves framebuffer/compositor/UI correctness — never a V3D triangle.
To Sigil-Drivers, for reading the actual code behind a name twice before wiring anything to it — catching a non-cryptographic formula mislabeled as Ed25519, and then catching a real Ed25519 implementation with a fatally short-lived key — on a security root of trust that both Apps and Code would otherwise have built on top of. Neither catch was glamorous. Both were exactly the discipline that keeps a signing chain meaning something.