Skip to content

Block Valve

Complete

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:

OperationDescription
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:

  1. NexFS allocates a buffer in its address space
  2. The Block Valve maps that buffer for DMA
  3. The hardware reads/writes directly to/from NexFS's buffer
  4. No kernel copy. No intermediate buffer.

This is specified in SPEC-700 (Zero-Copy DMA).

Released under the CC0 License.