Block Valve
Direct-test data proof
The Block Valve is the kernel's storage interface. It enforces a strict separation: the kernel passes sectors; it does not interpret them.
Design
In a traditional OS, the filesystem runs inside the kernel. A bug in ext4, NTFS, or ZFS can crash the entire system. The Block Valve rejects this design:
┌──────────────────────────────┐
│ Application │ Reads/writes files
├──────────────────────────────┤
│ NexFS (Userland Fiber) │ Interprets filesystem structures
├──────────────────────────────┤
│ Block Valve (Kernel) │ Passes raw sectors, nothing more
├──────────────────────────────┤
│ VirtIO Block Driver (HAL) │ DMA to/from hardware
└──────────────────────────────┘The Block Valve provides exactly three operations:
| Operation | Description |
|---|---|
block_read(lba, count) | Read count sectors starting at logical block address lba |
block_write(lba, count, data) | Write count sectors starting at lba |
block_info() | Return device geometry (sector size, total sectors) |
That's it. No open, no close, no seek, no ioctl. The Block Valve does not know what a file is, what a directory is, or what a superblock is.
Security
Access to the Block Valve requires an explicit capability in the fiber's CSpace. The NexFS fiber holds the block device capability. Application fibers do not — they communicate with NexFS through the VFS ION Ring (0x2000), which provides a file-level API.
This means:
- An application cannot bypass NexFS to read raw sectors
- A compromised application cannot corrupt the filesystem
- NexFS mediates all storage access through capability checks
Zero-Copy DMA
On hardware that supports it, the Block Valve uses zero-copy DMA:
- NexFS allocates a buffer in its address space
- The Block Valve maps that buffer for DMA
- The hardware reads/writes directly to/from NexFS's buffer
- No kernel copy. No intermediate buffer.
This is specified in SPEC-700 (Zero-Copy DMA).
M9 proof status
The Linux-side Block Valve shim is direct-test proven. In the M9 direct-test guest, nexus_blk.ko registers nxblk0, backs reads and writes with in-memory storage, and passes a BLK_REQ/BLK_RESP write/read roundtrip.
The proof-mode Linux NipCell also loads nexus_blk inside the staged Rumpk-spawned guest and reports nxblk0 major=252 ready.
Still open: a real cross-boundary Block Valve exchange between Rumpk and the Linux guest over the mapped ION rings.