gVisor — Container Sandbox with User-Space Kernel

Introduction

gVisor is an open source application kernel written in Go that implements a substantial portion of the Linux system call surface in user space. A container runs inside the sandbox via the runsc OCI runtime; every syscall the app makes is intercepted and handled by gVisor rather than the host kernel, dramatically shrinking the host attack surface. It's the sandbox behind Google App Engine, Cloud Run, and Cloud Functions, with over 18,000 GitHub stars.

What gVisor Does

• Implements Linux syscalls in a user-space kernel called the Sentry.
• Intercepts app syscalls via ptrace (compat) or KVM (fast) so the host kernel sees only the sandbox.
• Presents a standard OCI runtime (runsc) drop-in-compatible with Docker, Kubernetes, and containerd.
• Mediates filesystem I/O via the Gofer process for defense-in-depth.
• Adds isolation for untrusted multi-tenant workloads with minimal boot overhead.

Architecture Overview

gVisor runs three processes per sandbox: the Sentry (the user-space kernel), one or more Gofer processes (file I/O proxies), and the workload itself. The Sentry implements 200+ Linux syscalls, netstack for TCP/IP, and VFS for filesystems — all in memory-safe Go. On x86_64 with KVM, runsc uses the KVM platform for near-native performance; the ptrace platform works anywhere but is slower. Because syscalls never reach the host directly, a container escape requires compromising the Sentry first, a tiny, auditable target compared to the full Linux kernel.

Self-Hosting & Configuration

• Install the runsc binary and register it as a Docker/containerd/CRI-O runtime.
• Use --runtime=runsc in Docker, or set a RuntimeClass gvisor in Kubernetes and pin pods to it.
• Choose platform in /etc/docker/daemon.json — runtimeArgs: ["--platform=kvm"] for speed on bare metal.
• Tune network mode: --network=sandbox for the netstack stack, or --network=host for host netns.
• Monitor with the built-in metrics exporter (Prometheus-compatible) and runsc debug.

Key Features

• VM-like isolation without starting a VM — one Go process per sandbox.
• Drop-in OCI runtime works with Docker Compose, Kubernetes, Nomad, and containerd.
• Memory-safe Go kernel limits the blast radius of a compromise.
• KVM platform keeps overhead to 10-30% for typical workloads.
• Production-hardened by Google for multi-tenant SaaS and CI workloads.

Comparison with Similar Tools

• Firecracker — KVM microVM; stronger hardware-level isolation, requires nested virt on cloud.
• Kata Containers — VM-per-pod using QEMU or Firecracker; heavier, more compatible.
• Docker default (runc) — native Linux namespaces; fastest and most compatible, weakest isolation.
• Nabla containers — unikernel approach; niche and less mature.
• Bubblewrap/Sandboxie — desktop sandboxes; not suited for server workloads.

Key Trade-offs

• Some syscalls and filesystems are unimplemented or slow; eBPF and io_uring support is limited.
• Suited for stateless web services, CI jobs, untrusted code execution, and multi-tenant SaaS isolation.

FAQ

Q: Does gVisor support GPUs? A: Yes, via nvproxy for NVIDIA GPUs — a proxy that forwards CUDA calls while maintaining isolation.

Q: Is it a replacement for runc? A: For untrusted workloads, yes. For trusted high-performance code, runc is usually still preferred.

Q: Can I run Docker-in-Docker inside gVisor? A: Not reliably — nested containerization hits unimplemented features.

Q: How does it compare to seccomp? A: Seccomp restricts syscalls; gVisor reimplements them. It's a much stronger boundary.

Sources

• https://github.com/google/gvisor
• https://gvisor.dev/docs/