gVisor

Anyone who runs foreign program code on their servers takes on a risk. A malicious program could try to break out of its assigned area. It would then gain access to the data of other customers on the same machine. gVisor is software from Google designed to prevent exactly that. It wraps around the foreign program like a protective layer. All requests that the program makes to the computer first pass through gVisor and are checked there.

Why foreign code is so dangerous

Cloud providers rent out computing power. On a single physical server, the programs of dozens of customers often run simultaneously. Usually they are separated from each other using containers. A container is an isolated area in which a program runs with everything it needs. The catch: all containers on a server share the same operating system kernel.

This kernel is called the kernel. It manages memory, disk, and network for all programs. The Linux kernel consists of millions of lines of code and offers more than 300 different commands. With that much code, errors are inevitable. If an attacker finds such a gap, they can break out of their container. Experts call this a container escape.

For AI companies, this problem has become very relevant. Modern language models write program code and execute it themselves, for instance to check a calculation. This code is generated spontaneously and has not been reviewed by any human. Yet it still has to run somewhere without causing harm.

The kernel as a rebuild in the in-between space

gVisor solves the problem with an additional layer. A program called Sentry places itself between the application and the real kernel. The Sentry itself behaves like a kernel: it receives the application’s commands and answers most of them on its own. It is written in the programming language Go, which rules out many typical memory errors from the outset.

The decisive point is the reduction of the attack surface. Instead of more than 300 kernel commands, only a few dozen now reach the real kernel, and these are strictly filtered. An attacker would therefore have to overcome two layers of protection in succession. An analogy: a visitor never speaks directly to the boss, but always to an assistant who checks and forwards every request.

This security comes at the cost of performance. Every detour through the Sentry takes time. For programs that work heavily with files or the network, gVisor can be noticeably slower than a normal container. For pure computation, on the other hand, the difference is barely noticeable. So one has to weigh which tasks justify the overhead.

From the Google data center into AI tools

Google has been using gVisor in its own operations for years, among other things for the cloud service App Engine and for Cloud Run. The software is open source, so anyone can download it for free and inspect the code. In practice, one encounters it under the name runsc, which is the name of the executable program.

gVisor is especially interesting wherever AI systems act autonomously. When a chatbot writes and executes code, it needs a sandbox — a safe play area from which nothing leaks to the outside. Providers of coding assistants and so-called agents therefore rely on such technology. An alternative are tiny virtual machines like Firecracker, which recreate a complete computer.

A common misconception is that gVisor is a virtual machine. That is not true. No complete computer is recreated; only the operating system’s interface is intercepted. That is why gVisor starts in fractions of a second rather than in seconds. In reports on cloud security, the term usually appears as shorthand for this in-between solution.