[pdfinn]

Summary

On bare metal, a key is now made only from a hardware generator. A board whose generator is missing or not working used to hand libsec's key generators, #c/notquiterandom and #c/random a predictable counter after one console line. It now fails closed. The Pi's generators are also read under a lock, and the RNG200's own health-test flags are now heeded.

This follows up the open question left in #658, now that the Pi boards are real. Refs: INFR-404, INFR-342 (F2/F4).

Changes

• os/port/random.c now owns genrandom, prng and prngtry, which all six boards had copied. genrandom waits for real bytes and says why every five seconds. prngtry answers -1 at once with no generator, as libsec.h documents.
• The hwrandom contract: bytes (>0), dry (0), or no generator (-1). It never makes bytes up.
• insecurerandom on the boot command line gives an emulator a labelled counter. The harness passes it to QEMU's raspi4b, and os/mpfs/qemu-icicle.dts sets it. A board's cmdline.txt must not.
• os/port/devcons.c: the seed behind nrand, used for port and TCP sequence numbers, no longer reads the pool, so networking never waits.
• os/bcm/rng200.c (new) is shared by the Pi 4 and, once its port merges, the Pi 5. It sits at the board's RNG200REGS, reads a word under a lock, and resets the block when the NIST-fail or lockout flag is set, as Linux's iproc-rng200 does. os/bcm2711/random.c is removed. The BCM2837 leaves the file out.
• os/bcm2837/random.c: the check for a word and its read are one step under a lock, and the spin counter is per call.
• os/mpfs/random.c: -1 when the nonce service refused at boot. If the service stops later, keys wait instead of switching silently to the counter.
• os/virt/random.c, os/riscvvirt/random.c: -1 with no source. Calls before the probe read as dry.
• Docs: the changelog, docs/TLS-ENTROPY.md (whose opening table was stale), docs/BAREMETAL-BOARD-INTERFACE.md, and the board READMEs.

Testing

Run locally under QEMU: 9.2.4 with the repo's patches for AArch64, 8.2 for RISC-V.

• tests/host/baremetal_test.sh: 527 passed, 1 failed, 1 skipped.
  • The failure is the bcm2837 JIT nil-dereference check. Its output has every expected line, but the shell prompt landed at the start of one, and the check matches at line start. I did not rerun it on master.
  • The skip is the fsck.fat image check.
• tests/host/baremetal_riscv64_test.sh: 70 passed, 0 failed, 0 skipped.
• New on virt with no virtio-rng: the machine reaches its shell; reads of /dev/notquiterandom and /dev/random wait and say why; no counter appears; nothing panics. With insecurerandom, both answer and the counter is labelled.
• raspi4b reaches the Lucifer desktop with insecurerandom and checks the label. So does the Icicle Kit.
• The Pi 5 (feat/pi5-port with this merged, plus a small patch) builds with the shared driver.

Not verified:

• Nothing has booted on a physical board.
• The RNG200 health-flag reset has never executed: QEMU has no RNG200.
• The Pi 4's fail-closed path is not covered under QEMU on its own, since every Pi 4 boot passes insecurerandom. Only virt checks the refusal.

Checklist

• Code follows the existing style of the file(s) modified
• No .dis build artifacts committed from appl/ or tests/
• Documentation updated
• No secrets, API keys, or credentials included

Follow-ups (not in this PR)

• The Pi 5 adaptation (delete os/bcm2712/random.c, add RNG200REGS) belongs on feat/pi5-port once it takes this.
• A ChaCha20 conditioner in front of the hardware and a repeat-word health test on raw output.
• An SP 800-90B measurement on each board.

🤖 Generated with Claude Code

https://claude.ai/code/session_0195u6z4TJx1xi2fTM3X596h

[pdfinn]

iOS Build & Simulator Test is red here, and it is not this PR's.

• What fails: the app builds and installs on the simulator, then verify gets an empty console and no hello_test PASS. It reports VERIFY FAILED: expected test PASS output not found (job).
• The base is red the same way. Master's head, 62ce2a6, fails the same job with the same empty console and the same line (job). It passed on 5ca892f, this PR's original base.
• The diff can't reach it. This PR changes only the bare-metal kernels under os/, their QEMU tests, and docs. The iOS app builds the hosted emulator (emu/) and bundles dis, tests and lib, none of which changed. Master's commits since 5ca892f are Raspberry Pi Imager metadata, which doesn't reach iOS either.
• No fix exists yet. I could not re-run the job, because this integration gets a 403 on re-runs.

The earlier red, on the bcm2711 job, was this PR's: the release's Pi 4 card was booted under a QEMU with no RNG200, and d580729 fixes it.

---

Generated by Claude Code

[pdfinn]

Linux AMD64 Host Tests (1) is red with two failures, and neither is this PR's. Master's head, 62ce2a6, fails the same shard with the same two tests (job).

• devletters_test: ported the existing fix. prof: the profiling device is #K, and prof(1) has a /prof to bind on #1037–emu: wmsz to #z and 2fa to #h, off the watchdog's and flash's letters #1040 merged around the registry, so #K, #X, #x, #z and #h were in use but still marked reserved in docs/DEVICE-LETTERS.md. The fix is DEVICE-LETTERS: the five moves are made; their rows say so #1048, which is open. I cherry-picked its commit, d147d1b, as 87c4d6d. Locally the test went from 0 passed, 5 failed to passed, here and on master. It is the same change, so DEVICE-LETTERS: the five moves are made; their rows say so #1048 will still merge cleanly.
• tools9p_integration_test: no fix exists yet. It fails with FAIL: child provisioning did not preserve covered descendant path (output: git/fs mounted on /mnt/git ...), on master too. This PR changes nothing in tools9p, Veltro or the hosted emulator. Master went red on it after the recent tools9p merges, and I found no open PR addressing it. I left it alone rather than widen this PR. I can't re-run jobs from this session; the integration gets a 403.

---

Generated by Claude Code

[pdfinn]

macOS ARM64 Build & Test went red on d580729, but none of its build or test steps failed. The one failed step is "Upload macOS build artifacts" (step 20): Failed to CreateArtifact: Unable to make request: ECONNRESET, a connection reset during the upload to GitHub (job).

The wallet persistence lines in that log are marked non-fatal in CI, and master's passing run of this job prints the same ones. That head has been superseded by 87c4d6d, which runs the job again. I can't re-run jobs from this session; the integration gets a 403.

---

Generated by Claude Code

[pdfinn]

macOS ARM64 Build & Test and iOS Build & Simulator Test never ran on 87c4d6d. GitHub cancelled both after 15 minutes: "The job was not acquired by Runner of type hosted even after multiple attempts," with a macOS arm64 capacity warning. Neither has a result to judge.

They need a re-run. I can't trigger one from this session, because the integration gets a 403.

The rest of CI on this head: every bare-metal job passed (bcm2837, bcm2711 with the card boot, virt, and both RISC-V jobs). devletters_test now passes. The only test failure left is tools9p_integration_test, which is red on master too, as described above.

---

Generated by Claude Code

[pdfinn]

Linux AMD64 SDL3 GUI Build & Test timed out on 87c4d6d, and the base is red in the same step.

• What happened here: the job hit its 60-minute limit inside "Run Xenith and display host tests" (step 17). GitHub keeps no log for it (BlobNotFound), so I can't name the test that ran long.
• Master is red in the same step. On master's head, 62ce2a6, that step failed with wmsize_test: FAIL: /dev/wmsize gave '', want 'm 640 400 ...' (job).
• The diff can't reach it. This PR changes only the bare-metal kernels under os/, their QEMU tests and docs. The GUI job builds and runs the hosted emulator, Xenith and the display tests, none of which this PR touches.

No fix exists that I can port. I can't re-run the job from this session.

---

Generated by Claude Code