gVisor

gVisor is an open-source workload isolation solution designed to safely run untrusted code, containers, and applications. Unlike traditional isolation methods, gVisor acts as an application kernel that runs in userspace.

Core Architecture

• gVisor Sentry: The kernel-like component that intercepts and handles system calls and page faults from the sandboxed workload. It is a Go-based reimplementation of the Linux system call interface, memory management, filesystems, network stack, and more.
• Gofer: A sidecar process that acts as a slightly-more-trusted companion running in a slightly-more-privileged context to handle requests that the Sentry cannot service within its restricted environment.

Key Security Properties

• No System Call Passthrough: The Sentry never passes a sandboxed system call directly to the host kernel. If a feature is not reimplemented in gVisor, the workload cannot use it.
• Defense-in-Depth: While gVisor uses Linux kernel security primitives (like seccomp-bpf, namespaces, and cgroups), it uses them to protect the Sentry itself from the host, rather than using them as the primary way to sandbox the workload.
• Memory Safety: The Sentry is written in Go, which eliminates many common memory-safety vulnerabilities found in traditional guest kernels.

In gVisor's Netstack, bufferv2 is a high-performance, non-contiguous, reference-counted, pooled, and copy-on-write buffer abstraction. It was designed to replace standard Go byte slice allocations to reduce Garbage Collection (GC) pressure in networking workloads.

Internal Structure

A Buffer is implemented as a linked list of Views. Each View contains start/end indices and points to a Chunk. A Chunk is a reference-counted structure allocated from a tiered pool of byte slices.

Key Features

• Zero-cost copies & Copy-on-Write (CoW): Cloning a Buffer only increments the reference count of the underlying chunks. If a buffer is modified, only the specific chunk being changed is cloned, rather than the entire buffer.
• Fast Transformations: Operations like truncating, merging, appending, or prepending views are efficient because they primarily involve linked-list manipulations or index changes.
• Tiered Pools: To handle varying packet sizes without excessive memory waste or constant reallocations, bufferv2 uses multiple pools with different chunk sizes (starting at 64 bytes and doubling up to 64k).

Directfs is a filesystem access mode in runsc that provides gVisor's application kernel (the Sentry) with secure, direct access to the container filesystem.

How it works

Historically, gVisor used a "gofer" (a trusted filesystem proxy) to handle all filesystem operations via RPCs. This added significant overhead.

With Directfs, the gofer still exists but acts as a setup process rather than a proxy for every operation:

1. The gofer enters a new mount namespace and sets up appropriate bind mounts to create the container filesystem.
2. The gofer uses pivot_root(2) to enter that directory.
3. The sandbox (Sentry) enters its own user and mount namespaces and pivot_root(2)s into an empty directory to prevent path traversal escapes.
4. Instead of making RPCs, the gofer sends file descriptors (FDs) for all mount points to the sandbox using SCM_RIGHTS messages.
5. The sandbox then performs filesystem operations directly using file-descriptor-relative syscalls (e.g., fstatat(2), openat(2), mkdirat(2)).

Security Model

Directfs relies on Linux filesystem isolation primitives (mount namespaces, pivot_root, and detached bind mounts) rather than just syscall filtering. The sandbox is restricted to the FDs provided by the gofer and cannot walk backwards (using ..) or follow malicious symlinks to escape the container filesystem.