gVisor
| gVisor | |
|---|---|
| Developer | |
| Release | 2 May 2018 |
| Written in | Go |
| Operating system | Linux |
| Platform | x86-64, ARM64 |
| License | Apache License 2.0 |
| Website | gvisor |
| Repository | github |
gVisor is an open-source container sandbox developed by Google that focuses on security, efficiency, and ease of use.[1][2] It provides virtualization-like isolation while maintaining the resource efficiency of standard containers. gVisor intercepts application system calls and implements a large portion of the Linux system call ABI in userspace, offering additional security compared to standard containers that run directly on top of the Linux kernel and are isolated merely with namespaces.[3][4] Unlike the Linux kernel, gVisor is written in the memory-safe programming language Go to prevent common pitfalls which frequently occur in software written in C.[5] Modern features of the platform include checkpoint/restore functionality, runtime monitoring integration (such as with Falco), and GPU/CUDA isolation for AI/ML workloads.[6]
According to Google[7] and Brad Fitzpatrick,[8] gVisor is used extensively in Google's production environment, including the App Engine standard environment, Cloud Functions, and Google Cloud Run.[9] Furthermore, gVisor is integrated with Google Kubernetes Engine (GKE Sandbox), allowing users to sandbox their Kubernetes pods for use cases like SaaS and multitenancy.[10]
Beyond Google, gVisor is adopted by numerous organizations to secure their container and application infrastructure. Notable adopters include DigitalOcean for its App Platform, Cloudflare for Cloudflare Pages builds, and AI companies like OpenAI and Anthropic to safely execute untrusted code or high-risk tasks. Additionally, projects like Docker (in its Mac desktop version) and Tailscale rely on gVisor's network stack library for userspace networking.[11]
Architecture
[edit]gVisor acts as an application kernel, it intercepts and handles system calls and page faults from the sandboxed workload itself, rather than passing them to the host Linux kernel.[12]
- The Sentry is the core component of gVisor. It is a userspace kernel, written in Go, that implements a large subset of the Linux system-call interface along with subsystems such as process management, signal handling and networking. The logic runs entirely within gVisor's memory-safe code rather than being delegated to the host kernel.[12][13]
- The Gofer is a separate, slightly more privileged sidecar process that mediates access to the host filesystem. The Sentry cannot open host files directly; file operations are sent to the Gofer over the 9P protocol, adding a further layer of isolation between the sandbox and host resources.[12]
To minimize the attack surface exposed to the host, the Sentry runs under a restrictive seccomp filter and in isolated user and mount namespaces, so that even the small set of host system calls it can make is tightly constrained.[12]
Platforms
[edit]gVisor must intercept the sandboxed application's system calls and redirect them to the Sentry. It abstracts this behind a "platform" interface, of which two are currently provided:
- Systrap uses the seccomp-bpf subsystem's
SECCOMP_RET_TRAPfeature: a sandboxed system call triggers aSIGSYSsignal that hands control to gVisor. It requires no hardware virtualization and works even inside virtual machines, making it the most portable option. Systrap replaced the older ptrace platform as the default in mid-2023.[14]
- KVM uses the kernel's KVM functionality, letting the Sentry act as both guest kernel and virtual machine monitor. It performs best on bare-metal hosts but suffers under nested virtualization and is unavailable on hardware lacking the relevant virtualization extensions.[14] The original ptrace platform, based on
PTRACE_SYSEMU, remains in the codebase but is no longer supported.[14]
Performance
[edit]Because Sentry intercepts and replays the system calls, gVisor adds overhead that falls most heavily on system-call–intensive and I/O-intensive workloads, while having little effect on workloads that remain within their own address space. gVisor's own documentation notes that raw memory access and sequential disk I/O incur no significant structural overhead once mappings are established.[15]
An independent USENIX case study found that calls reaching the host or the Gofer were substantially slower than operations serviced entirely within the Sentry, and concluded that system-call–heavy workloads should avoid the ptrace platform. [13]
References
[edit]- ↑ Google Cloud Platform: Open-sourcing gVisor, a sandboxed container runtime
- ↑ "gvisor.dev". gvisor.dev. Retrieved 2019-05-28.
- ↑ "Updates in container isolation". LWN.net. Retrieved 18 February 2019.
- ↑ "Sandboxing with gVisor". 17 June 2018. Retrieved 18 February 2019 – via Medium.
- ↑ Cutler, Cody; Kaashoek, M. Frans; Morris, Robert T. (2018). The benefits and costs of writing a POSIX kernel in a high-level language. pp. 89–105. ISBN 978-1-939133-08-3.
- ↑ "Features - gVisor". gvisor.dev. Retrieved 2026-06-03.
- ↑ "GKE Sandbox: Bring defense in depth to your pods". Google Cloud Blog. Retrieved 2019-05-28.
- ↑ "Brad Fitzpatrick Twitter". Retrieved 18 February 2019 – via Twitter.
- ↑ "Container runtime contract | Cloud Run". Google Cloud. Retrieved 2019-04-10.
- ↑ "GKE Sandbox". Google Cloud. Retrieved 2019-05-28.
- ↑ "Who's Using gVisor". gvisor.dev. Retrieved 2026-06-03.
- 1 2 3 4 "Introduction to gVisor security". gvisor.dev. Retrieved 25 June 2026.
- 1 2 Li, Yuwei; et al. (2024). "G-Fuzz: A Directed Fuzzing Framework for gVisor". arXiv:2409.13139 [cs.CR].
- 1 2 3 "Platform Guide". gvisor.dev. Retrieved 25 June 2026.
- ↑ "Performance Guide". gvisor.dev. Retrieved 25 June 2026.
 | This Google-related article is a stub. You can help Wikipedia by adding missing information. |
