SWITCH — M-Gated LOAD Lifecycle
Current contract · Task 3193
SWITCH CRd, CRs, #row is the special LOAD into isolated
CR12–CR15. CRs must be CR0–CR11. A malformed operand faults
INVALID_OP; a clear destination M bit faults PERM_L. The source needs normal
L authority and no M. Success loads the entry and consumes destination M.
Historical notice: The expandable diagram below documents
the superseded PassKey/sentinel proposal. It is retained for design history
and is not the current instruction or security model.
Archived PassKey-era lifecycle diagram
Phase 0 — Namespace Birth
Once only — at manufacture or first configuration
Before any GT exists there is nothing — no namespace, no permissions, no authority.
The root of trust must be created from randomness. This is turning lead into gold:
inert random data becomes an unforgeable Abstract GT that anchors all future authority.
Hardware RNG
128-bit secret — known to nobody yet
Mint.Encode( type=Abstract, ab_data=secret, perms=none )
NS_IDENTITY_GT
Abstract GT · no NS entry · no permissions · gt_seq=0
This word IS the root of trust — value-in-token, unforgeable
Copy A
Mint's private c-list
Never shared. This is Mint's proof that it is the legitimate issuer for this namespace.
Copy B
Namespace owner
The "owner credential". Must be kept secret. Required to authorise any future SWITCH.
After Phase 0, exactly two parties hold the NS Identity: Mint and the namespace owner.
No instruction can derive, copy (B=0), or forge it.
Phase 1 — Boot Sequence
Every power-on — Boot ROM with M-elevation
The boot ROM runs with m_elevated=1 permanently asserted.
This bypasses the L-permission check inside mLoad, allowing the namespace root
to be loaded before any GT authority exists. NS integrity32 is still verified —
the boot image must contain correct pre-computed hashes.
SWITCH is not used during normal boot.
B:00
FAULT_RST — clear all CRs, DRs; M-elevation ON
LEDs = 0b000001
B:01
LOAD_NS — mLoad( NS[0] = Boot.NS ) → CR15
M-elevation bypasses L-perm · integrity32 still verified · CR15: NULL → namespace root
B:02
INIT_THRD — mLoad( NS[1] = Boot.Thread ) → CR12
B:03
INIT_ABSTR — mLoad( NS[3] = Boot.Abstr ) → CR6
B:04
LOAD_NUC — CR14 ← Boot.Abstr code region
LEDs = 0b111111 · Boot.Abstr executes → Startup.Config.Execute()
Register state after boot:
| Register | Contents | Scope |
|---|
CR12 | Thread Stack GT | System-wide — unchanged by CHANGE |
CR13 | NULL or boot default | System-wide — unchanged by CHANGE |
CR14 | Boot.Abstr code GT | Per-thread — re-derived on every CALL |
CR15 | Boot.NS root GT | System-wide — unchanged by CHANGE |
Phase 2 — PassKey Issuance
Runtime — required before any SWITCH can execute
The caller must prove namespace ownership to Mint before Mint will produce a PassKey.
Without this upstream gate, the hardware checks in Phase 3 would be trivially bypassable
by anyone who could place any Abstract GT into a source CR.
Caller presents NS_IDENTITY_GT to Mint
Mint.IssuePassKey( NS_IDENTITY_GT, target = CR15 )
Does NS_IDENTITY_GT match Mint's stored copy?
MATCH
Mint.Encode( type=Abstract )
word1_location = 0xFFFFFFFF (CR15 sentinel)
— or —
word1_location = 0xFFFFFFFE (CR13 sentinel)
PassKey Abstract GT issued
B=0 — cannot be copied by user code (mSave faults)
Mint.Transfer → caller's CR (e.g. CR0)
Mint places it directly; no mSave needed
NO MATCH
REFUSE — fault
No PassKey issued.
Caller cannot SWITCH anything.
Sentinel values — 0xFFFFFFFF (CR15) and 0xFFFFFFFE (CR13) —
sit at the top of the hardware I/O address range. No live lump base address can ever occupy
these locations, so there is no ambiguity with a real memory capability.
Phase 3 — The SWITCH Instruction
Hardware FSM — hardware/switch.py
SWITCH CR0, #7 — CR0 holds the PassKey; #7 is the Tgt field for CR15
(dest_cr = CR8 + Tgt = CR15). Five sequential checks before mLoad.
①
CHECK_TARGET — is Tgt ∈ {5, 7}?
5 → CR13 7 → CR15 → proceed to ②
Any other value → INVALID_OP fault
②
CHECK_SRC — is source CR index in range 0–7?
In range → proceed to ③
Out of range → INVALID_OP fault
③
READ_SRC — latch full contents of source CR
PassKey capability latched into src_reg → proceed to ④
④
CHECK_PASSKEY_TYPE — is src.word0_gt.gt_type == 0b11 (Abstract)?
Abstract GT confirmed → proceed to ⑤
Inform, Outform, or NULL → INVALID_OP fault
⑤
CHECK_PASSKEY_SENTINEL — does src.word1_location match the expected sentinel for this target?
Sentinel matches → proceed to ⑥
Mismatch (e.g. CR13 PassKey presented to CR15 target) → INVALID_OP fault
⑥
ChurchMLoad( src=CR0, dst=CR15, m_elevated=1 )
L-permission check bypassed (m_elevated) ·
NS integrity32 verified ·
gt_seq revocation check ·
g-bit reset ·
CR15 ← new capability ·
thread table shadow updated
Any mLoad failure → fault propagated
SUCCESS
CR15 holds the new namespace root
CR0 is unchanged — one-way install, not a swap.
Change is system-wide and immediate.
FAULT
INVALID_OP (checks ①–⑤) or mLoad fault (⑥)
CR15 unchanged. Fault handler invoked.
Complete Chain of Trust
Phase 0: Random Number
→
NS_IDENTITY_GT
→
Mint (private copy)
↑ owner also holds a copy — never shared with anyone else
Owner presents NS_IDENTITY_GT
→
Mint verifies identity
→
PassKey issued (sentinel set)
B=0 on PassKey — cannot be copied by user code
Mint.Transfer → caller's CR
→
SWITCH CRn, #target
① target valid?
→
② src in range?
→
③ Abstract GT?
→
④ sentinel ok?
→
⑤ mLoad validates
CR13 or CR15 updated — system-wide, immediate
Five Guarantees
| Guarantee | Enforced by |
|---|
| Only the namespace owner can trigger a SWITCH |
Mint refuses PassKey issuance without NS_IDENTITY_GT (Phase 2) |
| A PassKey for CR13 cannot install into CR15 |
Sentinel check in hardware FSM — check ④ |
| No ordinary capability (Inform/Outform) can be SWITCHed |
Abstract GT type check in hardware FSM — check ③ |
| The capability being installed is authentic and unrevoked |
mLoad NSGate: integrity32 + gt_seq check — check ⑤ |
| The old CR15/CR13 value is not secretly moved anywhere |
One-way install — source CR unchanged; no swap behaviour |
What Hardware Alone Cannot Enforce
The hardware FSM checks ①–④ verify the form of the PassKey but have no knowledge
of whether Mint verified the NS Identity before issuing it. The full chain depends on three
software conditions:
1. Mint's private c-list must be unreadable by any user-level code.
2. NS_IDENTITY_GT must never be placed in a bindable (B=1) slot —
propagation beyond the initial two holders breaks the guarantee.
3. Mint must refuse all PassKey requests that do not present the matching
NS_IDENTITY_GT.
If any of these three software conditions fail, the hardware checks are insufficient —
a forged PassKey could reach SWITCH and succeed.
The hardware is the last line of defence, not the only one.
Current Simulator Status (D-11)
The simulator does not implement this design.
_execSwitch in simulator/simulator.js performs a plain atomic CR swap
(cr[src] ↔ cr[target]) with only a NULL check on the source.
No type check, no sentinel check, no target restriction, no mLoad.
Any register 0–7 can be the target. This reflects the old pre-PassKey design.
Fix tracked as Task #880. Hardware is the reference.
Related Files
| File | Role |
|---|
hardware/switch.py | Hardware FSM — five checks + mLoad call |
hardware/mload.py | ChurchMLoad — NS validation, g-bit reset, CR write |
hardware/hw_types.py | Sentinel constants, GT type constants, Tgt field values |
simulator/simulator.js | _execSwitch — current stale implementation (pre-PassKey) |
docs/HARDWARE-DEVIATIONS.md | D-11 — SWITCH hardware vs simulator gap |
docs/switch-lifecycle.md | This document in Markdown form |
docs/mint.md | Mint issuance protocol, Abstract GT note (§9) |
docs/abstract-gt.md | Abstract GT word layout and ab_type registry |
docs/namespace-security.md | mLoad validation pipeline, NS entry format |
Confidential — Kenneth Hamer-Hodges — May 2026