NipCells

Proof-mode Linux guest boot proven

NipCells are isolated execution environments for Nexus packages and foreign payloads. They cover two related cases:

• Application NipCells: lightweight package isolation for NPKs.
• Linux NipCells: RumKV/Rumpk-spawned foreign kernel cells for hardware drivers and legacy payloads.

The first M9 Linux NipCell proof now boots a staged ARM64 Linux guest to /init and loads the Nexus bridge modules. Production start wiring and real cross-boundary Block Valve exchange remain open.

What Is a NipCell?

A NipCell is a sandboxed execution environment for an NPK (application package). It provides:

• Filesystem isolation: GoboLinux-style symlink trees give each application its own view of the filesystem
• Capability restriction: Each NipCell gets a tailored capability set (pledge mask + unveil paths)
• Resource limits: Kinetic Economy budgets prevent resource abuse
• Clean removal: Uninstalling a NipCell removes all its files, state, and capabilities

Linux NipCell proof status

The current M9 proof is a dedicated QEMU proof build. It proves that Rumpk can stage a real ARM64 Linux Image, enter it through the EL2 handoff, map the shared ION window, and let Linux load the bridge modules.

Verified markers:

Proof marker	Status
Stage-2 ION map 0x90000000 -> 0x5F000000	Proven
ION header seeded and validated by Linux	Proven
Linux /init starts	Proven
nexus_ion loads	Proven
nexus_net reports nx0 ready	Proven
nexus_blk reports nxblk0 major=252 ready	Proven
nexus_input reports ready	Proven

Remaining work:

• Wire the staged handoff into the default nipcell_start_result() path.
• Add a guest console policy for the initial-console warning.
• Add a reserved-memory or allocator guard for the shared ION window.
• Prove real cross-boundary Block Valve traffic over the guest rings.

For the proof command and exact evidence boundary, see Nexus-Linux NipCell.

How NipCells Work

/Programs/Firefox/120.0/        # Package files (read-only)
/Cell/<fiber-id>/               # Private runtime state
/Bus/hud/<surface-id>           # Display endpoint
/Data/apps/firefox/             # Persistent app data

The NipCell creates a filesystem view that combines:

1. Read-only access to the package directory
2. Private runtime state in /Cell
3. Persistent data in /Data/apps/
4. Nothing else (unless explicitly unveiled)

NipCells vs Flatpak

Feature	Flatpak	NipCells
Runtime size	~500MB per runtime	No runtime — packages are self-contained
Isolation	bwrap + seccomp	Capability Algebra + pledge/unveil
Deduplication	Shared runtimes	CAS-level deduplication via NexFS
Portal system	D-Bus portals	ION Ring endpoints in /Bus
Update mechanism	OSTree deltas	DAG-based incremental updates
Dependency model	Runtimes + extensions	Flat dependency resolution via nip

NipCells vs Docker

NipCells are for applications, not services. For service-level isolation, see Nexters.

Key difference: NipCells use capability-based isolation (no virtualization, no namespaces, no cgroups). They are much lighter than Docker containers — startup is near-instant because there is no container runtime to initialize.