From 21168f99daf8b7d0ada303f508af0f276cbb2912 Mon Sep 17 00:00:00 2001 From: Robert Allan James Date: Sat, 22 Aug 2026 06:30:43 -0400 Subject: [PATCH] FABRIC-2.md Section U addendum: foreign-drive protection, zuse one-way burn, console/VM key-match attachment -- still brainstorming, nothing implemented Three more requirements captured while fresh, same design session: (7) home-blocks write path must check for a home-blocks signature before ever writing to an inserted drive, warn and refuse on foreign/ unrecognized/blank media instead of silently claiming it; (8) zuse credential minting is one-way, asymmetric with an operator drive's presumed re-provisioning path; (9) console/VM split -- console is generic and shared, drive insertion spins up a per-identity VM (a Tripod-birth-mechanism consumer), and console-to-VM attachment is a key/lock match, structurally similar to ACL-PIN's existing key model but not yet confirmed to reuse it directly. Co-Authored-By: Claude Sonnet 5 --- FABRIC-2.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/FABRIC-2.md b/FABRIC-2.md index a7f535b..332c9cf 100644 --- a/FABRIC-2.md +++ b/FABRIC-2.md @@ -2611,3 +2611,45 @@ Natural next steps, none begun: (a) settle the hotwords-cache-reuse question fro open point, (b) decide on the identity→block-range derivation function (item 3), (c) scope the minimal USB xHCI + MSC bulk-only read/write driver as its own milestone, sized against virtio-blk's build-out for comparison. + +**Addendum, same session, three more requirements while fresh:** + +7. **Foreign-drive protection — a hard precondition on the write path, not yet in the design + above.** Before any home-blocks write path touches an inserted USB drive, it must check for + a signature confirming the drive is already a minted home-blocks drive (analogous to a + filesystem superblock magic number, consistent with this project's existing content- + addressed-everything approach — e.g. an XXHash64-verified header block, matching the + pattern capsules already use for identity). If the signature is absent, or the drive + carries a foreign filesystem (Windows, Linux, blank, anything unrecognized), the system + must warn and refuse to write rather than silently claiming/overwriting it. Section U's + original design (items 1-6 above) implicitly assumed every inserted drive was already a + minted home-blocks drive; this closes that gap. +8. **Zuse minting is one-way — asymmetric with Captain Bob's drive.** Once a drive is burned + as the zuse superuser credential, it cannot be re-minted or overwritten, ever — a strictly + harder constraint than an operator drive (which presumably can be re-provisioned if lost or + replaced). The two physical thumb drives from the Phase 8 PKI context above are *not* + symmetric in how their write/re-mint paths should behave, even though both are "thumb + drives" in the general sense — the zuse path needs its own one-way-burn guard, distinct + from whatever re-provisioning path an ordinary operator drive gets. +9. **Console/VM split — attach-by-key, not attach-by-identity-check.** The *console* (the + physical/session-level interface — what a person actually sits down at) is generic and + shared, with no identity bound to the console itself; anyone can attach to a console. + Plugging in a USB drive is what spins up a **VM** for that specific identity — a natural + consumer of the existing Tripod birth mechanism (Hera already births VM patrons; this would + be another trigger for that same mechanism, driven by drive insertion rather than a capsule + load). The console then must bind to *exactly one* VM — the one belonging to the identity + that just plugged in — via a key/lock match: the console presents a key, the VM (or its + home-blocks range) carries a matching lock, and the two only attach on a match. Captain + Bob's own framing: "receptors," a lock-and-key/DNA-matching model, structurally the same + shape as `ACL-PIN`'s existing key-based permission model, just applied to console→VM + binding instead of word-level execution permission — **open question, not yet settled:** + whether this literally reuses the `ACL-PIN`/`acl_allow` mechanism (extended to gate console + attachment the same way it gates word execution) or needs its own separate key-matching + primitive. Confirmed shape (Captain Bob, verbatim confirmation this session): "console + attaches to a user's VM... solves just its own VM, that's all it's gonna be" — one console, + one VM, exactly, for the duration of that binding. End-to-end flow as currently understood: + insert USB drive → drive's credential authenticates and spins up (or re-attaches to) that + identity's VM → console presents its key → key matches the VM's lock → console is now + attached to that VM and only that VM → "I have permission to use a [thumb drive as a + credential] tool. I'm gonna use a console. Simple as that" (Captain Bob, describing the + intended user experience end state).