Expand description
nixvm — a portable, VM-style sandbox that runs a real Linux userland by emulating Linux syscalls directly.
There is no guest kernel and no device emulation. Guest processes run on the
host CPU (via Hypervisor.framework or KVM) or a software interpreter; when a
process makes a syscall the CPU traps out and kernel::Kernel services it
entirely in userspace, under nixvm’s resource limits.
§Module map
abi— the Linux ABI as data: errno, per-arch syscall tables.vcpu— execution backends (hvf,interp) behind one trait.loader— ELF loading, stack/auxv setup.fs— the VFS mount table (squashfs, overlay, passthrough, …).kernel— the arch-agnostic syscall engine + process state.image— guest root-image resolve/download/cache.sandbox— the publicSandboxbuilder that wires it all together.
unsafe is confined to the hardware backend (vcpu::hvf); everything else
is safe Rust.
use nixvm::Sandbox;
// Run `npm install` in a sandbox with the cwd mounted at /work.
let status = Sandbox::builder()
.command(["npm", "install"])
.run()?;
std::process::exit(status);Re-exports§
Modules§
- abi
- Linux syscall ABI surface: the facts of the kernel ABI — error numbers, syscall numbers, and C struct layouts — so the loader, kernel, and backends all agree on the same numbers. Pure data + tiny helpers; nothing executes.
- fs
- The nixvm virtual filesystem.
- image
- Guest root images: resolve a name → a local squashfs file, downloading and verifying it into a content-addressed cache on first use.
- kernel
- The nixvm “kernel”: an arch-agnostic engine that services guest syscalls and schedules multiple guest processes.
- loader
- Turning an ELF file into a ready-to-run guest process image.
- sandbox
- The public entry point: build a sandbox, then run a command in it.
- vcpu
- Execution backends: run guest code until it needs the kernel.
- vm
- Interactive VM driver — boot a root image and drive it a step at a time, feeding terminal input and draining output between steps.
Enums§
- Error
- The crate’s top-level error.