If you’ve ever tried to run gVisor on a Raspberry Pi 5 and hit a cryptic failure, you’re not alone. The root cause turns out to be a single kernel configuration option, one that most people have never heard of. Let’s dig into what it is, why it matters, and how to fix it.
What Is gVisor, and Why Should You Care?
Before we get into the weeds of virtual address spaces, a quick refresher on what gVisor actually does.
Regular containers (Docker, containerd, etc.) are fast and lightweight, but they share the host kernel. That means a compromised container could potentially attack the host OS, a real concern in multi-tenant or security-sensitive environments. Virtual machines solve this with strong isolation, but at the cost of booting a full separate kernel, pre-allocating memory, and added overhead.
gVisor sits in between these two worlds. It implements a Linux kernel entirely in userspace (called the Sentry) and intercepts all syscalls from your container, handling them in its own sandboxed kernel rather than passing them to the host. Your container thinks it’s talking to a normal Linux kernel; in reality, it’s talking to gVisor. Only a very small, carefully filtered set of host syscalls ever reaches the real kernel. The result is VM-like isolation with container-like efficiency.
Figure 1: gVisor architecture: the Sentry intercepts all container syscalls and mediates access to the host kernel through a minimal interface (Source: CNCF)
To put it differently: with KVM or Xen, your workload runs inside a hardware-enforced virtual machine managed by a hypervisor. With gVisor, your workload runs inside a userspace-enforced sandbox managed by a software kernel. No VM overhead, no pre-allocated guest memory, no separate boot sequence, but a very strong security boundary.
This makes gVisor a great fit for running untrusted workloads, adding defense-in-depth around sensitive services, or just experimenting with sandboxed containers on edge hardware like a Raspberry Pi 5.
A Quick Detour: How Virtual Memory Addressing Works
Now, about that kernel configuration option. To understand why it matters, we need to take a short detour into how virtual memory works on 64-bit ARM.
... continue reading