Sandbox Isolation for Untrusted Workloads: gVisor vs Firecracker vs Kata Containers

#Start here: the basics in plain words

A normal container is just a Linux process with a restricted view of the system. It sees its own files, its own process list and its own network. But it still talks directly to the host's kernel, the same kernel every other container on that machine uses. If the code inside finds one kernel bug, it owns the machine and every other customer on it.

When you run code you didn't write (customer CI jobs, student code submissions, AI-agent tool calls, serverless functions), you need a second wall. There are three common designs:

A system call (syscall) is how a program asks the kernel to do something: open a file, send a packet, start a process. Linux has about 450 of them, and every one is a door into the kernel. Sandboxes differ in who answers those doors:

                runc                  gVisor                 Firecracker / Kata
            ┌──────────┐          ┌──────────┐            ┌──────────────────┐
            │   app    │          │   app    │            │   app            │
            └────┬─────┘          └────┬─────┘            │   guest kernel   │ ← its own Linux
                 │ ~450 syscalls       │ ~450 syscalls    └────────┬─────────┘
                 │                ┌────▼─────┐                     │ virtio devices,
                 │                │  Sentry  │ ← Go "kernel"       │ VM exits
                 │                └────┬─────┘                ┌────▼─────┐
                 │                     │ few dozen host       │   VMM    │ ← Rust (Firecracker)
                 │                     │ seccomp-filtered     └────┬─────┘   or C (QEMU)
            ┌────▼─────────────────────▼──────────────────────────▼─────┐
            │                      host Linux kernel (+ KVM)             │
            └────────────────────────────────────────────────────────────┘

Memory hook

"who answers the syscall?" runc: the host kernel. gVisor: a Go program pretending to be a kernel. Firecracker/Kata: a real guest kernel, with hardware keeping it in a box. Every security and performance difference below follows from that one question.

#Threat Model and Boundary Architecture

What is this?The threat model says what the attacker controls and what they want. For untrusted workloads the attacker controls all code inside the sandbox, often as root, and wants one of three things: the host, another tenant's data, or the platform's credentials.

Why it mattersInterviewers use this topic to see if you know that "container" and "security boundary" aren't the same word. The strong answer names the attack surface each design exposes, not just "VMs are safer".

How it works

🎯

On the job. When someone says "we sandbox it", ask three questions: what runs the syscalls, what host process sits on the other side of the wall, and what privileges does that host process have. The answer to the third one is usually where the next escape lives.

#Attack Surface and Mediation Layers

What is this?A mediation layer is any code that receives input from the untrusted side and acts on the host side. Each one is an attack surface.

Why it matters"VMs are safer" is only true if the code on the host side of the wall is small and careful. QEMU's floppy controller (VENOM, CVE-2015-3456) proved that a big device model is a big target.

How it worksEach design's host-side surface, smallest first:

Key ideas behind the table:

In practiceHow to tell, from inside a job, which sandbox you're in:

$ uname -r                         # inside gVisor
4.4.0                              ← gVisor reports a fixed, old-looking version
$ dmesg | head -3
[   0.000000] Starting gVisor...   ← the Sentry's own fake boot log
[   0.412345] Reticulating splines...
[   0.723456] Ready!

$ cat /sys/class/dmi/id/sys_vendor  # inside Firecracker: no DMI tables at all
cat: /sys/class/dmi/id/sys_vendor: No such file or directory
$ ls /sys/bus/virtio/devices/
virtio0  virtio1                   ← only a network and a block device

🎯

On the job. In a design review of a Kata deployment, check virtiofsd's flags: is --sandbox set (it chroots or namespaces itself), is seccomp on, and does it run as root? CVE-2026-47243 below was exactly "root, sandbox off, seccomp off".

#Escape History and Vulnerability Case Studies

Last verified2026-10

What is this?A "sandbox escape" is when code that is supposed to stay inside the sandbox manages to do something outside it: read the host's files, run a program on the host, or reach another customer. This section walks through real escape bugs, one at a time, assuming you've never seen any of them.

Why it mattersIn an interview, "VMs are safer than containers" is a weak answer. A strong answer is "here is a real bug from this year, here is the exact piece of code that failed, and here is the setting that would have limited the damage". You can only say that if you understand each bug in plain terms.

#First, the idea every escape uses

Think of the sandbox as a prison cell with a hatch in the door. The prisoner can't walk out, but they can pass notes through the hatch: "please give me this file", "please send this packet". A guard on the other side reads each note and acts on it.

• The prisoner is the untrusted code.
• The notes are requests: system calls, disk reads, file operations.
• The guard is the host-side program that handles them: gVisor's Sentry or Gofer, Firecracker itself, or Kata's file server virtiofsd.

Nobody escapes by breaking the wall. They escape by writing a note the guard misunderstands. If the guard misreads a note and does something harmful, the prisoner gets whatever power the guard has. That's why the guard's own privileges matter so much: a guard who is locked in a small room themselves (an unprivileged user, in a chroot, with seccomp) can't do much harm even when fooled. A guard with the keys to the whole building (root, no sandbox) can.

#Firecracker: a device setting changed at the wrong time (CVE-2026-5747)

The pieces you need to know

• A virtual machine needs a network card and a disk, but they're not real hardware. Firecracker pretends to be them. Those pretend devices use a standard design called virtio.
• The guest and Firecracker exchange data through shared queues: lists in memory saying "here's a packet to send", "here's a block to read". Before using a device, the guest tells Firecracker where each queue is and how big it is, by writing to the device's configuration registers (think of them as the device's settings form).
• There are two ways for the guest to reach those settings, called transports. The old default is MMIO (memory-mapped I/O). Firecracker 1.13 added an optional, faster one: PCI (the same bus real network cards use), switched on with --enable-pci.
• An out-of-bounds write means a program writes data past the end of the memory it set aside. It overwrites whatever happens to be next to it, which can crash the program or, if the attacker controls what's written, take over the program.

What went wrongThe rules say the guest sets up queues, then "activates" the device, and doesn't touch those settings again. With the PCI transport, Firecracker didn't stop a guest that broke that rule. A guest root user could activate the device and then change the queue settings, for example its size. Firecracker kept using its old assumptions about the queue, and ended up writing outside the memory it had reserved.

Why it's badThe bad write happens inside the Firecracker process, which is on the host side of the wall. At minimum the guest can crash its own VMM. With extra conditions (AWS named a custom guest kernel or specific snapshot setups) it could potentially run code on the host as the Firecracker process.

📰

Real incident — Firecracker virtio-pci out-of-bounds write (CVE-2026-5747, April 2026). AWS bulletin 2026-015: affected Firecracker 1.13.0–1.14.3 and 1.15.0 on x86_64 and aarch64; fixed in 1.14.4 and 1.15.1. Only the opt-in PCI transport was affected; the default MMIO one wasn't, and AWS said none of its own services were. Lesson: Firecracker is small and written in Rust, a language that prevents most memory bugs, and it still got one in a new, optional feature. Every feature you turn on is new code the guest can talk to. And this is where the jailer earns its keep: it runs each Firecracker process as an unprivileged user inside a chroot with seccomp, so even if the attacker takes over Firecracker, they're a user who can barely do anything on the host.

#Kata: a settings field that let tenants pass orders to the host (CVE-2026-44210)

The pieces you need to know

• In Kubernetes, anyone allowed to create a pod can attach annotations to it: free-form key: value labels. Kata reads some of them to let a pod tune its VM, for example "give my VM these extra kernel options".
• virtiofsd is the program on the host that shares a folder with the VM (this is how the container's files appear inside the VM). Like any program, it takes command-line flags that decide its behaviour, including which host folder to share.
• "Argument injection" means an attacker gets to add their own flags to a command that someone else runs.

What went wrongBefore Kata 3.31.0, the default configuration accepted an annotation called virtio_fs_extra_args, whose whole purpose was "add these flags to virtiofsd". So a tenant could write, in their own pod definition, flags that told the host's virtiofsd to share a different folder, the host's root folder /, instead of the container's files. A second default-allowed annotation, kernel_params, could switch on Kata's debug console inside the VM, giving an easy shell to use it.

Why it's badNo hacking skill was needed: no memory corruption, no exploit code, just a pod with two annotations. From inside the VM, the attacker could then read or change any host file, such as /etc/shadow (the host's password hashes).

📰

Real incident — Kata virtiofsd argument injection (CVE-2026-44210, May 2026). Fixed in Kata 3.31.0 by no longer allowing those annotations by default. Lesson: the wall between guest and host isn't only code, it's also every setting the tenant is allowed to choose. If a customer can type something that ends up as a flag on a root program on the host, that's a hole in the wall, however good the hypervisor is.

#Kata: the file server followed a shortcut out of its folder (CVE-2026-47243)

The pieces you need to know

• FUSE (Filesystem in Userspace) is a protocol for "please do this file operation": open, read, create, rename. virtiofsd receives FUSE requests from the VM and performs them on the host's disk.
• A symlink (symbolic link) is a file that just points to another path, like a desktop shortcut. Programs that follow symlinks without care can be led to a place they never meant to touch.
• Path traversal is the general name for tricking a program into working on a path outside the folder it should be limited to.
• /etc/cron.d/ is a host folder where every file is a scheduled job that the host runs as root.

What went wrongIn Kata's newer Rust runtime (runtime-rs) with the "standalone" virtio-fs setup, virtiofsd ran as root, with its own sandbox switched off and seccomp switched off. A root user in the guest could hand-craft FUSE requests that made virtiofsd create symlinks pointing outside the shared folder, for example into /etc/cron.d. Writing through them dropped a scheduled job onto the host.

Why it's badThe host's cron then ran the attacker's command as root. That's a complete escape: from inside the VM to full control of the host and every VM on it.

📰

Real incident — Kata runtime-rs virtiofsd escape (CVE-2026-47243, May 2026). Fixed in Kata 3.31.0. Lesson: sharing a folder means the host follows file paths that the guest chose. Getting that perfectly right is hard, so you need a second line of defence. Had virtiofsd run with its sandbox on (locked into the shared folder) and seccomp on, the same mistake would have hit a wall.

#gVisor: which kinds of bugs matter

gVisor has fewer published escapes, and its bugs fall into different shapes. In the prison analogy, gVisor has two guards, and both are locked in small rooms.

🎯

On the job. Two checks you can do today. First, for Kata: open configuration.toml and look at enable_annotations. That list is "settings tenants may change on the host"; virtio_fs_extra_args and kernel_params shouldn't be on it. Second, for every runtime: find the host-side "guard" process (firecracker, virtiofsd, runsc-gofer) with ps -o user,args and confirm it isn't root and is sandboxed. Watch each project's GitHub Security Advisories page.

In practiceThe Kata setting behind CVE-2026-44210:

# /opt/kata/share/defaults/kata-containers/configuration-qemu.toml (pre-3.31-style defaults)
[hypervisor.qemu]
shared_fs = "virtio-fs"
enable_annotations = ["virtio_fs_extra_args", "kernel_params"]   ← tenants can pass host flags

# Hardened
enable_annotations = []                                          ← tenants tune nothing on the host
virtio_fs_extra_args = ["--thread-pool-size=1", "--announce-submounts"]

#Tracing a Kernel Exploit Through Each Sandbox

What is this?A "kernel exploit" attacks a bug in Linux itself, the core program that controls the machine. Whoever controls the kernel controls everything on it. Here we take two real kernel bugs and ask, for each sandbox: which kernel does the attack actually hit, and what does the attacker get?

Why it mattersThis is the clearest way to show you understand the difference between the sandboxes. runc, gVisor and VMs give three different answers to the same attack, and the reasons are the core of this whole page.

#Dirty Pipe (CVE-2022-0847)

The pieces you need to know

• A pipe is a kernel feature for passing data between programs, as in cat file | grep x.
• The page cache is the kernel's memory copy of files that were recently read. When anyone reads /usr/bin/sudo, the kernel keeps it in memory, and the next program to run sudo gets that in-memory copy. There's one page cache per kernel, shared by every program and every container on it.
• splice() is a shortcut system call that moves file data into a pipe without copying it, by pointing the pipe straight at page-cache memory.

What went wrongA flag inside the pipe code wasn't reset properly. After a splice(), an attacker could write into the pipe and the kernel would write those bytes straight into the page-cache copy of a file, even a file the attacker only had permission to read. The file on disk didn't change, but every program using the in-memory copy saw the attacker's version.

Why it's badOverwrite the in-memory copy of a root-owned program, or of the password file, and you become root. From a container it's worse: the page cache belongs to the host kernel, so a container can change files the host and other containers are using.

#An RxRPC out-of-bounds write

The pieces you need to know

• RxRPC is an old, rarely used network protocol (it carries the AFS network filesystem). Almost nobody needs it, but its code ships with Linux, and it has had several memory bugs over the years.
• Linux loads optional code (modules) on demand. On many distributions, simply asking to open an RxRPC socket, socket(AF_RXRPC, …), makes the kernel load the RxRPC module for you.
• So any program can drag a rarely tested piece of kernel code into memory and then send it crafted packets that trigger the out-of-bounds write (writing past the end of a buffer, as explained above).

Why it's a good exampleIt shows that a big kernel's danger is all the code you don't use but can still reach.

Memory hook

"gVisor removes the bug; a VM contains the bug." Under gVisor the vulnerable kernel code is simply not in the path, so most kernel exploits fail outright. Under a VM the exploit succeeds, but against a throwaway kernel inside a box. That's why the strongest setups combine both, like GKE Sandbox running gVisor on nodes that are themselves VMs.

📰

Real incident — runc /proc/self/exe (CVE-2019-5736). runc is the program that starts containers on the host. A malicious container could open the runc program itself through a special path (/proc/self/exe, which always points to "the program running me") and overwrite it. The next time anyone started a container, the host ran the attacker's code as root. Under gVisor or a microVM the same trick only reaches the sandbox's own files. Lesson: with plain containers, even the tool that builds the wall is within the attacker's reach.

#Hardware Virtualisation and Platform Diversity

Last verified2026-10

What is this?The sandboxes depend on CPU features, and fleets mix CPUs: AMD EPYC and ARM64 servers (AmpereOne) on bare-metal racks, plus Apple Silicon Macs for macOS builds.

Why it matters"Just use Firecracker" fails if your hosts are cloud VMs without nested virtualisation, or Macs. The right answer depends on the hardware.

How it works

• KVM on AMD EPYC (x86_64) — AMD-V with nested page tables. Firecracker, Kata and gVisor-KVM all work. Optional AMD SEV-SNP (Secure Encrypted Virtualization) encrypts guest memory so even the host can't read it; Kata supports it for confidential containers.
• KVM on AmpereOne (ARM64) — Arm virtualisation extensions (the hypervisor runs at exception level EL2). Firecracker, Kata (QEMU, Cloud Hypervisor) and gVisor (systrap and KVM) all support arm64. AmpereOne cores are single-threaded (no SMT), which removes a whole class of cross-hyperthread leaks.
• Cloud VMs as hosts (AWS/GCP) — Firecracker and Kata need /dev/kvm, so they need bare-metal instances (e.g. AWS .metal) or nested virtualisation (GCP supports it on many machine types). gVisor's systrap platform needs no virtualisation at all, which is why it fits ordinary cloud VMs.
• Apple Silicon (M4 / M5 Max) with Apple Virtualization (vz)
  • Apple's Virtualization.framework sits on Hypervisor.framework. It runs each VM in a sandboxed per-VM helper process and offers mostly virtio devices.
  • macOS guests: Apple's licence allows at most two extra macOS VMs per Mac, and the framework enforces it. Density is therefore 2 macOS jobs per machine, no matter how much RAM it has.
  • Linux guests: no such limit; density is bounded by RAM and cores. Nested virtualisation (KVM inside a Linux guest) needs M3 or later with macOS 15, so M4/M5 can run Firecracker inside a Linux VM on a Mac.
  • Automation: image cloning uses APFS copy-on-write; VMs boot in seconds, but there is no Firecracker-style snapshot restore at fleet scale, and host re-imaging between tenants is part of the boundary.

🎯

On the job. On a macOS fleet, the second VM slot is the multi-tenancy question. If two customers share one Mac's two slots, a hypervisor bug or a leftover file in a shared cache crosses tenants. Many platforms give each tenant the whole Mac for the lease and wipe it between leases.

#Side Channels: What No Sandbox Stops

What is this?Every escape above needed a software bug. A side channel needs none. Two programs running on the same CPU share parts of it, and one can learn the other's secrets by watching how the shared hardware behaves, not by reading the data directly.

An everyday picture: you share an office kitchen with a stranger. You can't open their lunchbox, but if the microwave is warm and smells of curry, you know what they ate. CPUs have their own "warm microwaves":

Why it mattersEvery sandbox here, gVisor, Firecracker and Kata, runs the untrusted code directly on the real CPU, so all of them share the CPU with their neighbours. gVisor's own security guide says plainly that it doesn't stop hardware side channels, and a VM boundary doesn't either. This is the one class of attack where "use a stronger sandbox" doesn't help; you have to change where code runs.

How it works

What to configure:

In practice

$ cat /sys/devices/system/cpu/smt/control
on                                  ← EPYC host with SMT on: needs core scheduling or pinning per tenant
$ grep . /sys/devices/system/cpu/vulnerabilities/* | head -4
…/vulnerabilities/retbleed:Mitigation: untrained return thunk; SMT enabled with STIBP protection
…/vulnerabilities/spec_rstack_overflow:Mitigation: Safe RET
…/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; STIBP: always-on
…/vulnerabilities/mds:Not affected

#Performance Profiling and Bottlenecks

Last verified2026-10

What is this?Where each sandbox loses speed, and what that means for picking one.

Why it mattersSecurity people who pick a sandbox that makes builds three times slower lose the argument. You need to know which workloads suffer.

How it works

In practiceWhat a gVisor penalty looks like in a build (illustrative timings; measure your own workload):

$ time npm ci          # runc
real    0m21.4s
$ time npm ci          # runsc, systrap, overlay rootfs
real    0m48.9s        ← ~2× slower: ~1.2M file syscalls answered by the Sentry
$ time make -j32       # CPU-bound C compile, same tree
real    3m02s vs 3m09s ← almost no difference once the work is in the CPU

#Network Isolation and Egress Filtering

What is this?How each sandbox's network traffic leaves the machine, and how you control where it goes.

Why it mattersMost real damage from untrusted code isn't an escape, it's the network: stealing cloud credentials from the metadata service, scanning the internal network, or sending stolen secrets home.

How it works

A good egress design for multi-tenant jobs:

In practiceThe host-side rules for one Firecracker VM's tap device:

table inet vm_egress {
  chain fwd {
    type filter hook forward priority 0; policy drop;
    iifname "tap-job812" ip daddr 169.254.169.254 drop     ← no cloud metadata
    iifname "tap-job812" ip daddr 10.0.0.0/8 drop           ← no internal network
    iifname "tap-job812" ip daddr 10.255.0.10 tcp dport 3128 accept   ← egress proxy only
  }
}

🎯

On the job. From a test job, run curl -m 2 http://169.254.169.254/latest/meta-data/ and curl -m 2 https://example.com without the proxy. Both should fail. Then check the proxy's logs show your test job's tenant ID next to each destination: without that, you can't investigate an exfiltration.

#In Practice: Hardening Multi-Tenant CI/CD Workloads

What is this?Putting it together for a platform that runs customers' GitHub Actions and Buildkite jobs, including Docker BuildKit and shell builds, on bare-metal Kubernetes.

Why it mattersThis is the system-design version of the question, and it's where interviewers check you can connect sandboxes, identity and network.

How it works

In practiceThe Kubernetes side:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: kata-fc
handler: kata-fc                     # containerd maps this to Kata + Firecracker
scheduling:
  nodeSelector: { pool: untrusted-metal }
  tolerations: [{ key: untrusted, operator: Exists, effect: NoSchedule }]
---
apiVersion: v1
kind: Pod
metadata: { name: job-812, namespace: tenant-acme }
spec:
  runtimeClassName: kata-fc          ← the line that makes this a VM, not a container
  automountServiceAccountToken: false  ← the job must not get a Kubernetes API token
  containers:
    - name: runner
      image: registry.internal/runner@sha256:4c1e…
      env: [{ name: RUNNER_JITCONFIG, valueFrom: { secretKeyRef: { name: job-812-jit, key: cfg } } }]
      resources: { limits: { cpu: "8", memory: 16Gi } }

Things that commonly go wrong:

🎯

On the job. Review the runner controller's code (often Go): how is the JIT token passed to the pod, does it ever land in logs, and is the Kubernetes Secret deleted when the job ends? A token printed in a pod event or a debug log is a token anyone with log access can replay until it's used.

#Runtime Decision Matrix

Last verified2026-10

What is this?A way to pick a sandbox per workload, instead of one answer for everything.

Operational trade-offs to say out loud: