ZViz vs gVisor
gVisor is a userspace kernel from Google: it emulates the Linux syscall ABI in a Go runtime called Sentry. ZViz uses kernel primitives directly with a strict seccomp filter. Both are credible answers to "runc is not a security boundary."
Compared with: gVisor
| Aspect | ZViz | gVisor |
|---|---|---|
| Isolation mechanism | Layered kernel primitives (namespaces + capability drop + Landlock + seccomp-BPF + cgroups v2) | Userspace kernel (Sentry emulates ~300 syscalls) |
| Kernel attack surface | ~132 syscalls allowed, 24 denied at BPF, 1 argument-filtered | ~70 host syscalls reached via Sentry |
| Cold start (measured by repo demo) | ~8 ms | ~200 ms |
| Memory per container | ~2 MB (static Zig binary) | ~50 MB (Sentry process) |
| I/O throughput | ~95% of native | ~40% of native |
| clock_gettime | 20 ns (native vDSO) | 4,982 ns (Sentry cannot use vDSO) |
| read() | 212 ns | 4,393 ns |
| write() | 211 ns | 1,169 ns |
| ptrace() inside container | BLOCKED (EPERM) | ALLOWED (emulated in Sentry) |
| mount() inside container | BLOCKED (EPERM) | ALLOWED (emulated via Gofer) |
| unshare(NEWUSER/NEWPID/NEWNS) | BLOCKED | ALLOWED (emulated) |
| Docker-in-Docker | Not supported (needs mount/unshare) | Supported (Sentry emulates the namespaces) |
| Bazel / Nix sandboxed builds | Not supported (internal namespacing blocked) | Supported |
| strace / debuggers | Not supported (ptrace blocked) | Supported (ptrace emulated) |
| Default network egress | DENY (explicit allowlist required) | ALLOW (relies on network namespace) |
| Escape tests blocked (same 19-test bundle) | 19/19 (100%) | 11/19 (58%)* |
| Live security tests blocked (8 tests) | 8/8 | 6/8* |
| Policy compatibility | 98.2% (54/55 vs gVisor baseline) | baseline |
| Implementation language | Zig (static binary) | Go (Sentry runtime) |
| Daemon required | No (exec-replaces into PID 1) | Sentry process supervises |
| Hardware requirements | None (pure kernel primitives) | None |
| Linux kernel minimum | 5.13 (Landlock LSM) | 4.14+ |
| License | Apache 2.0 | Apache 2.0 |
* gVisor "allows" some operations because they are emulated inside the Sentry sandbox; the host kernel never executes them. Different philosophy, equivalent isolation for those specific operations. Numbers from the ZViz README and architecture/comparison.md in the source repository.
Pick gVisor when
You need Docker-in-Docker, Bazel/Nix internal sandboxing, ptrace/strace, or maximum syscall compatibility for legacy workloads that probe dangerous syscalls and handle the response.
Pick ZViz when
You need sub-10ms cold starts, native syscall throughput, the smallest possible memory floor per container, and strict default-deny posture for code you do not trust at all.
For a fuller treatment of these trade-offs, see the field note Isolation models, ranked by what they actually break.