gVisor - How is BPF used?

gVisor uses BPF (Berkeley Packet Filter) code extensively when using the Systrap platform, but it uses it in two very distinct ways: one for the "Trap" mechanism and one for "Observability."

It is important to distinguish between cBPF (Classic BPF, used by Seccomp) and eBPF (Extended BPF, used for tracing).

The Interceptor: Seccomp-BPF (cBPF)

The "Systrap" platform gets its name from "System Call Trap." It relies on a Seccomp filter to catch system calls.

• How it is used: Every time you start a gVisor sandbox, the Sentry installs a Seccomp-BPF program on the application process.
• The Code: This BPF code acts as a "firewall" for syscalls. It is programmed to say: "If any syscall is made, do not let it reach the host kernel. Instead, trigger a SIGSYS signal."
• Technicality: Seccomp officially uses cBPF (the older, simpler version of BPF). However, the Linux kernel internally JIT-compiles this into the same high-performance machine code used by eBPF.

Without this BPF code, Systrap cannot function. It is the "Tripwire" that notifies the Sentry that the application wants to do something.

The Observability Layer: gVisor Trace (eBPF)

In more recent versions of gVisor, a feature was added called gVisor Tracing. This is where true eBPF comes into play.

• The Problem: Because gVisor is a sandbox, standard host tools like strace or tcpdump don't always see the "truth" of what's happening inside the Sentry.
• The Solution: gVisor can generate eBPF programs and load them into the host kernel to monitor its own internal state.
• How it works:
  1. The Sentry has a "Trace" subsystem.
  2. When you enable it, it compiles and loads an eBPF program into the host kernel.
  3. This eBPF program hooks into the Sentry’s own syscalls or the Systrap signals to provide high-speed logging and monitoring of the sandbox’s health and performance.

Networking: XDP and AF_XDP (eBPF)

While not the default for every setup, gVisor has support for using eBPF/XDP to speed up networking.

• Netstack Efficiency: Standard networking in gVisor involves moving packets from the host's NIC through the Gofer/Sentry into the App. This is slow.
• eBPF Optimization: gVisor can use eBPF programs (XDP) to "grab" packets directly from the network card driver and bypass the host's standard networking stack, injecting them straight into gVisor’s internal Netstack.

Comparison: BPF in Systrap

Feature	Type of BPF	Role	Importance
Seccomp Filter	cBPF	The Trap. Intercepts syscalls and triggers signals.	Mandatory.
Sentry Tracing	eBPF	Observability. High-speed logging of sandbox events.	Optional (Debugging).
XDP/AF_XDP	eBPF	Networking. High-speed packet injection.	Optional (Performance).

Summary

If you are using Systrap, gVisor is always using BPF.

1. It uses cBPF as the physical mechanism to "catch" the application.
2. It uses eBPF as a high-performance tool to "watch" and "accelerate" the sandbox.

In gVisor's eyes, BPF is the "glue" that allows it to stay in user-space while still being fast enough to feel like a native kernel.