BoxLite vs gVisor: Hardware VMs vs Userspace Kernel

How does gVisor work?

gVisor is an application kernel, written in Go, that implements a substantial portion of the Linux system call interface. When a container runs under gVisor:

1. The container's syscalls are intercepted by Sentry (the userspace kernel)
2. Sentry implements the syscall logic in userspace, never passing most calls to the host kernel
3. Only a small set of whitelisted syscalls reach the actual host kernel via Gofer (for filesystem) and platform (ptrace or KVM)

This means even if an attacker exploits a kernel vulnerability, they're exploiting gVisor's userspace kernel—not the host kernel.

How does BoxLite work?

BoxLite uses hardware virtualization (KVM on Linux, Hypervisor.framework on macOS) to run each sandbox in a real micro-VM:

1. Each sandbox boots a real Linux kernel (provided by libkrun)
2. All syscalls are handled by that kernel—100% Linux compatibility
3. The VM boundary prevents any access to the host kernel

The trade-off is slightly higher overhead (separate kernel per sandbox) in exchange for complete compatibility and a simpler security model.

The compatibility question

gVisor's biggest limitation is syscall compatibility. While gVisor implements ~70% of Linux syscalls, some applications fail because they use unsupported or partially-supported syscalls.

Known compatibility issues with gVisor include:

• Some advanced networking features (raw sockets, certain ioctl calls)
• Certain filesystem operations
• Some GPU/hardware access patterns
• Applications using obscure kernel interfaces

With BoxLite, there's no compatibility question—if it runs on Linux, it runs in BoxLite. The sandbox has a real kernel with full syscall support.

Performance comparison

gVisor has two platform modes that affect performance:

• ptrace mode: Works anywhere but slower (syscall overhead)
• KVM mode: Faster but requires hardware virtualization

BoxLite always uses hardware virtualization (KVM/Hypervisor.framework), which provides good syscall performance but adds VM boot overhead.

General guidance:

• For syscall-heavy workloads: gVisor (KVM mode) may be faster
• For compute-heavy workloads: Similar performance
• For startup time: gVisor is faster (~200ms vs ~1s)
• For memory: gVisor uses less (~15-30MB vs ~50-100MB)

When to use gVisor

When to use BoxLite

Security model comparison

Both provide strong isolation, but with different approaches:

gVisor's security model

• Reduces attack surface by reimplementing kernel in userspace
• Host kernel only sees a small set of whitelisted operations
• Vulnerabilities in Sentry don't directly compromise the host
• Written in memory-safe Go (fewer memory corruption bugs)

BoxLite's security model

• Complete isolation via hardware VM boundary
• Guest kernel vulnerabilities can't reach host (different kernel)
• Same isolation model as traditional VMs, but lightweight
• Simpler to reason about: VM boundary = security boundary

Can I use both?

Potentially! You could run gVisor-protected containers inside BoxLite VMs for defense-in-depth. However, this adds overhead and complexity. In practice, choose the one that fits your needs:

• gVisor: When you want to harden existing container workflows
• BoxLite: When you need guaranteed compatibility or embeddable sandboxing

Summary

gVisor and BoxLite represent two philosophies for container security:

• gVisor: "Reimplement the kernel in userspace to reduce attack surface"
• BoxLite: "Use a real kernel but in a hardware-isolated VM"

If you're hardening known workloads and want minimal overhead, gVisor is excellent. If you're running arbitrary code and need guaranteed compatibility, BoxLite's hardware isolation is the safer bet.