nx_memcap.nx

memcap.nx -- CHERI-style memory capabilities, pure software. Pointer-with-bounds-and-permissions, implemented entirely in software. When Nishi silicon ships with hardware capabilities (CHERI-RISC-V extension, or our own), the compiler recognises MemCap<T> and emits single-instruction capability ops; the software runtime becomes a no-op or is replaced by the hardware path. Same NishiLang source, silicon-accelerated backend. This is the 40-year bet: build invariants in software now, keep the HW/SW interface stable, upgrade silicon when we can fab it. Distinct from runtime/cap.nx: that file covers ACCESS capabilities (who can call fs_open), which are coarse-grained and language-level. This file covers MEMORY capabilities (what bytes a pointer can touch), which are fine-grained and per- allocation. Both systems plug into the Nishi silicon story: access caps become compartment IDs, memory caps become CHERI pointer tags. Reference papers / systems: Watson et al 2015 "CHERI: A Hybrid Capability-System Architecture for Scalable Software Compartmentalization" Woodruff et al 2014 "The CHERI capability model" Nienhuis et al 2020 "Rigorous engineering for hardware security" Arm Morello -- production CHERI-Armv8 (2022) RISC-V CHERI extension -- ratified draft (2024) Layout (32 bytes in software): + 0 .. + 7 : address (i64, the actual pointer) + 8 .. + 15 : base (i64, lower bound inclusive) + 16 .. + 23 : length (i64, bytes from base) + 24 .. + 31 : perms + tag (packed i64) bit 0 : READ (load permitted) bit 1 : WRITE (store permitted) bit 2 : EXEC (jump permitted -- future) bit 3 : CAP_LOAD (can load a capability through) bit 4 : CAP_STORE (can store a capability through) bit 5 : SEAL (non-deref, unforgeable handle) bit 8 : VALID_TAG (mandatory; cleared on raw memcpy)