gVisor
By Google
gVisor is an open-source application kernel that sandboxes containers by intercepting their system calls in userspace and reimplementing a large part of the Linux kernel API itself, rather than passing calls through to the host kernel…
Definition
gVisor is an open-source application kernel that sandboxes containers by intercepting their system calls in userspace and reimplementing a large part of the Linux kernel API itself, rather than passing calls through to the host kernel unchecked. It gives containers an extra isolation boundary between the workload and the host kernel without requiring the workload to run inside a full virtual machine.
Overview
Standard containers isolate processes using Linux namespaces and cgroups, but every container still shares the host's kernel directly, so a vulnerability in the kernel's syscall handling can let a malicious or compromised container escape its sandbox. gVisor was built to reduce that risk without paying the cost of running every container in a full virtual machine. gVisor works by placing a userspace application kernel, called Sentry, between the container and the host. Sentry intercepts the container's system calls and either handles them itself using its own reimplementation of Linux kernel functionality, or forwards a much smaller, more restricted set of calls to the real host kernel through a separate process called Gofer. This means most of the surface a malicious container could attack never reaches the actual host kernel at all. This approach places gVisor between plain containers and full virtual machines on the isolation spectrum: it provides much stronger boundaries than namespace-based isolation alone, but with less overhead than tools like Firecracker or Kata Containers that wrap each workload in a real virtual machine. Unlike Kata Containers, which achieves isolation via a lightweight VM per container, gVisor achieves it primarily through syscall interception in userspace. gVisor integrates with container runtimes through runsc, a runtime that implements the OCI runtime specification so it can be used as a drop-in replacement for runc in Docker or Kubernetes, and it backs Google Cloud's gVisor-based sandboxing for multi-tenant container services. It is commonly chosen for running untrusted or third-party code in shared clusters where full VM isolation is considered too heavy operationally, and it can be applied selectively to only the pods or containers that actually handle untrusted input rather than the whole cluster. Because gVisor reimplements kernel functionality rather than passing calls through natively, some system calls and features are only partially supported or introduce performance overhead, particularly for I/O and networking-heavy workloads. Applications relying on obscure syscalls or kernel modules may not run correctly under gVisor, and workloads with strict low-latency I/O requirements can see a measurable slowdown compared with native containers. Teams generally weigh this overhead against the security benefit on a workload-by-workload basis, applying gVisor where the isolation gain justifies the performance cost and leaving trusted internal services on the default, faster runtime, an approach that keeps most of a cluster running at native speed while still hardening the specific pods that actually face untrusted input, and this selective, per-workload application is generally what makes gVisor's overhead acceptable in practice.
Key Features
- Intercepts container system calls with a userspace application kernel called Sentry
- Reimplements a large portion of the Linux kernel API independently of the host
- Restricts host kernel exposure through a separate Gofer file-access process
- Implements runsc, an OCI-compatible runtime usable as a drop-in for runc
- Provides isolation between namespace-based containers and full virtual machines
- Integrates with Docker and Kubernetes for sandboxed pod execution
- Open source and maintained by Google
- Supports per-container resource and syscall auditing