zviz

Overview

zviz investigates how little overhead a sandbox can impose while still containing untrusted code, which has become a practical question rather than an academic one now that models generate code that somebody has to run. The workload shape matters: running one long job is a different problem from running ten thousand short ones, and most sandboxing comparisons quietly assume the first.

The isolation model is selective denial. The runtime establishes user, PID, mount, IPC and UTS namespaces, drops all forty-one Linux capabilities, applies a Landlock LSM policy, installs a seccomp-BPF filter and places the process under cgroups v2. Of the syscall surface, 132 reach the host kernel at native speed, 24 are denied outright at the seccomp layer, and socket creation is filtered on its arguments rather than blocked wholesale.

That split is the entire performance argument. A userspace kernel intercepts and reimplements syscalls, paying a translation cost on every one; a microVM boots a guest, paying a startup cost on every execution. Selective denial pays neither, and concedes in exchange that the host kernel remains inside the trusted computing base. For short-lived executions at high frequency this is the right trade; for long-running workloads where boot cost amortises away, it is not.

zviz is OCI-compatible and ships as a single static binary with no daemon. That is an operational decision as much as a technical one: a sandbox that requires a privileged background service has expanded the attack surface it exists to reduce, and a static binary is something an operator can read, verify and deploy without a supervision tree.

Zig was chosen because this is systems programming with an unusual amount of compile-time policy generation, and comptime lets seccomp filters and capability sets be constructed during compilation rather than assembled at runtime. The cost is a small ecosystem and a language surface that is still moving, which is a real risk for infrastructure and one we accepted deliberately.

Where it loses, stated plainly: gVisor is mature, widely deployed and defends against a kernel exploit in a way selective denial cannot, and Firecracker's isolation boundary is stronger still. If the threat model includes a determined attacker with a kernel zero-day, zviz is the wrong choice. If the threat model is model-generated code that might do something careless at a rate of thousands of executions per minute, it is a good one.

A deployment note that matters more than it sounds: selective denial depends on the host kernel supporting the primitives it relies on, and Landlock in particular is a relatively recent addition. On an older kernel the policy degrades to what is available, which is a weaker boundary than the documentation's headline description, and an operator who has not checked may believe they have protection they do not. Verifying the kernel feature set at deployment time is part of using this correctly rather than an optional hardening step.

Within the portfolio, zviz is the containment half of a pair with gpuemu: one asks whether generated code can be run without harming the host, the other whether generated code computes what it claims. Neither answers the other's question, and a system that runs model-written code in production needs both.