firecracker VS gvisor

Source

Thanks for sharing! I'm not sure your table under Why Clone is quite correct.

10x 512MB idle VMs should not take 5GB on Firecracker if they are started from snapshots since the 512MB memory file is mmap'ed with MAP_PRIVATE so is copy on write.

Firecracker has diff snapshots: https://github.com/firecracker-microvm/firecracker/blob/main...

There are many good quick start documents 1 and blogs describing how to install and start a single Firecracker MicroVM instance. Because of these great resources readily available, I won't describe that here.

Well, FireCracker has a jailer process: https://github.com/firecracker-microvm/firecracker/blob/main...

Hello, I'm the CEO of the company that built this - E2B [0]. We're building infrastructure for AI code interpreting. Companies like Perplexity are using us.

We're using Firecrackers [1] to power our sandboxes. Funnily enough, we had this repo sitting on our GitHub for about 6 months. We originally made this for one of our customers because they were running evals on the desktop-like environment with GUI for their model.

You can use PyAutoGUI [2] to control the whole environment programmatically.

The desktop-like environment is based on Linux and Xfce [3] at the moment. We chose Xfce because it's a fast and lightweight environment that's also popular and actively supported. However, this Sandbox template is fully customizable and you can create your own desktop environment.

Let me know if you have any questions!

[0] https://e2b.dev

[1] https://github.com/firecracker-microvm/firecracker

[2] https://pyautogui.readthedocs.io/

[3] https://www.xfce.org/

Underneath the hood, Substrate uses gvisor (same thing as the Agent Sandbox project from the CNCF SIG), which is a container sandbox developed by Google that focuses on security, isolation, and the ability to use it in an efficient fashion (e.g - not take up a ton of hardware resources).

Consider gVisor for high-value workloads. Google's gVisor interposes a userspace kernel between your container and the host kernel. Your container's syscalls don't hit the real Linux kernel directly — they're intercepted by gVisor's Sentry process, which reimplements a subset of Linux syscalls in a sandboxed environment. A copy-primitive bug in the host kernel becomes unexploitable from inside the container because the container never makes the vulnerable syscall directly. The tradeoff is performance overhead and compatibility limitations. For multi-tenant or security-critical workloads, it's the strongest isolation you can get without a full VM.

You mentioned SECCOMP_RET_TRACE, but there is also SECCOMP_RET_TRAP which appears to perform better. There is also KVM. Both of these are options for gVisor: <https://github.com/google/gvisor>

The general trend in the AI tooling space is moving toward secure, sandboxed execution environments for agents. Projects like gVisor for kernel-level sandboxing and container-native solutions are making this easier. The pattern of separating inference from execution with a managed control plane in between is becoming standard for good reason — it's the only way to give agents real capabilities without creating real risks.

Gen1 (gVisor-based): gVisor is an open-source container sandbox developed by Google. It acts as a user-space kernel, a process written in Go that intercepts your container's system calls and reimplements them, so the host kernel is never directly exposed. This gives you a smaller attack surface and faster cold starts, but some software that relies on unusual system calls may be incompatible.

> Ultimately, if you fork() in gVisor, that calls fork() on the host

This isn't true. You can look at the code right here[1], there is no code path in gVisor that calls fork() on the host. In fact, the only syscalls gVisor is allowed to make to the host are listed right here in their seccomp filters[2].

[1] https://github.com/google/gvisor/blob/master/pkg/sentry/sysc...

It's terrifying how many of these people believe that containers are a security tool.

There's a reason why gVisor exists:

https://github.com/google/gvisor#why-does-gvisor-exist

There's a reason why secureblue doesn't use containers:

https://news.ycombinator.com/item?id=45045190

There's a reason why Qubes OS doesn't use containers.

While this is true, the general security stance on this is: Docker is not a security boundary. You should not treat it like one. It will only give you _process level_ isolation. If you want something with better security guarantees, you can use a full VM, something like gVisor[1] to limit the attack surface of a containerized process, or something like Firecracker[2] which is designed for multi-tenancy.

The core of the problem here is that process isolation doesn't save you from whole classes of attack vectors or misconfigurations that open you up to nasty surprises. Docker is great, just don't think of it as a sandbox to run untrusted code.

1. https://gvisor.dev/

2. https://firecracker-microvm.github.io/