SYSTEM Cited by 1 source
gVisor¶
gVisor is a Google-originated open-
source application kernel for containers: a user-space
process (runsc) that reimplements a large subset of the Linux
syscall interface and interposes between the container process
and the host kernel. Container syscalls hit gVisor's kernel
first; only a narrow, hardened subset reach the host. This
shrinks kernel attack surface
available to a compromised container process — a
concepts/container-escape now has to break gVisor plus the
host kernel.
(Source: sources/2026-04-21-figma-server-side-sandboxing-containers-and-seccomp)
Figma's framing¶
"Newer technologies like gVisor can reduce the attack surface available to containers by interposing its own hardened kernel between the OS kernel and the container process."
This is what makes gVisor a middle option between a stock
container (runC — full host-kernel surface
exposed) and a micro-VM (Firecracker —
hardware virtualisation boundary). Same OCI interface as runC
(gVisor can be a drop-in Docker runtime via --runtime=runsc),
different isolation posture underneath.
Trade-off axes¶
- ✅ Smaller kernel attack surface than runC — gVisor implements a filtered subset of Linux syscalls; everything else is refused before the host kernel sees it.
- ✅ OCI-compatible — drop-in under Docker / Kubernetes with runtime-class selection.
- ❌ Compatibility gaps — workloads that depend on
unimplemented syscalls,
/procpaths, or kernel features gVisor hasn't reimplemented fail. - ❌ Performance overhead — user-space syscall interception + reimplementation is measurably slower than direct kernel calls on syscall-heavy workloads (filesystem, networking).
Positioning in the sandboxing landscape¶
- vs systems/runc (same OCI surface, different backend): runC gives you kernel namespaces + cgroups + seccomp; gVisor gives you all that plus a user-space kernel layer in front of the host kernel.
- vs systems/nsjail (different UX): nsjail is a per-invocation command-line launcher stacking kernel primitives; gVisor is an OCI runtime with its own kernel in user space.
- vs systems/firecracker (different isolation strength): Firecracker uses hardware virtualisation; gVisor uses software interposition. The hardware boundary is generally stronger; gVisor is cheaper and denser-at-overhead.
Seen in¶
- sources/2026-04-21-figma-server-side-sandboxing-containers-and-seccomp — named as the container-attack-surface-reduction option when comparing VMs to containers.