gVisor - Sentry

The Sentry is the heart and soul of gVisor. If you think of gVisor as a "user-space kernel," the Sentry is the actual code that performs the role of the kernel.

It is called a "Sentry" because it stands guard between the untrusted application and the host operating system.

What exactly is the Sentry?

The Sentry is a large, complex process written in Go. It functions as a Guest Kernel.

When an application runs inside gVisor, it thinks it is talking to a standard Linux kernel. However, every time the application tries to do something (like open a file, send a network packet, or check the time), the Sentry intercepts that system call (syscall).

How it works?

In a normal container, if an app calls open(), the CPU switches to "Kernel Mode" and the host Linux kernel handles it.

In gVisor:

The Interception: The app calls open().
The Redirect: Instead of reaching the host kernel, the syscall is redirected to the Sentry (which is just another user-space process).
The Emulation: The Sentry looks at the request and says, "I know what an open() call looks like." It then processes the request using its own internal logic.
The Result: The Sentry returns a result to the app.

Crucially: The Sentry implements over 200 Linux system calls entirely in Go. It doesn't just "pass them through" to the host; it recreates the logic of the Linux kernel from scratch.

How does it intercept syscalls?

The core Sentry packages implement system calls, file systems, etc, but do not define how application code is executed or how system calls are intercepted. This behavior is defined by an implementation of the Platform interface.

Code: pkg/sentry/platform/platform.go

Key Components inside the Sentry

The Sentry is not just a simple proxy; it contains several full-scale operating system subsystems:

Netstack: A complete, high-performance network stack (TCP/IP, UDP, etc.) written in Go. When a container sends a packet, it is processed by the Sentry's Netstack, not the host's.
VFS (Virtual File System): Manages file operations and mounts.
Memory Management: Tracks the memory used by the application containers.
Scheduler: Manages the execution of threads within the sandbox.

Why was it written in Go?

Choosing Go for the Sentry was a deliberate security decision:

Memory Safety: Go prevents common vulnerabilities like buffer overflows and "use-after-free" errors, which are the most common ways attackers exploit real Linux kernels (written in C).
Type Safety: It reduces the chances of logic errors that could lead to a sandbox escape.

How does the Sentry catch the syscalls?

The Sentry needs a "Platform" to help it grab the syscalls from the application. It typically uses one of two methods:

PTRACE: The Sentry uses the standard Linux ptrace utility to "monitor" the app. (Slower, but works anywhere).
KVM: The Sentry acts as a small Hypervisor and uses the CPU's hardware virtualization features to intercept syscalls. (Much faster, but requires hardware support).

The "Sentry per Pod" Model

In Kubernetes, gVisor starts one Sentry per Pod.

All containers in that Pod (Main app, sidecars, log shippers) share that single Sentry.
Because they share one Sentry, they share the same Netstack (IP address) and VFS (Mounts), which is why they behave like a Pod.
However, they are all collectively isolated from the host kernel by that Sentry.

The Trade-off: Performance vs. Security

The Sentry is the reason gVisor is so secure, but it is also the reason for its main drawback: Performance Overhead.

Because every syscall has to be intercepted and handled by a user-space process (the Sentry), there is a "context switch" cost.

Compute-heavy apps (like video encoding) run nearly at full speed because they don't make many syscalls.
I/O-heavy apps (like high-traffic databases or web servers) see a performance hit because they are constantly asking the Sentry to "open," "read," "write," and "send."

Why Gofer is separate from Sentry?

The Sentry is heavily sandboxed using seccomp and has almost no access to the host.
The Gofer has slightly more privileges because it needs to actually open files on the host disk to give them to the Sentry.