Blastpen

← Back to blog

Isolation is almost free once you are inside it

Running a command inside a hardware-isolated virtual machine takes 5.6 milliseconds. Inside a plain process jail it takes 3.7. Almost the entire cost of the wall is in building it, not in living behind it.

Plan view of a room drawn inside another room: a thick hatched wall encloses an empty inner chamber outlined in red, with a dimension line and arrow terminators measuring how thin that wall actually is.

There is a belief about sandboxing that goes roughly: process isolation is cheap, hardware isolation is expensive, so pick your poison. Weak and fast, or strong and slow.

We measured it, and that framing is wrong in a way that changes how you should build things.

The numbers

  • create — process jail: 7.7 ms; hardware VM: 1.35 s
  • execute a command, warm — process jail: 3.7 ms; hardware VM: 5.6 ms
  • restore from a snapshot — process jail: —; hardware VM: 5 ms

Measured on a 12-core x86 Linux host with hardware virtualisation, warm image, single tenant, idle machine, trivial repository, no toolchain or dependency install. Your numbers will differ; the shape is what matters.

Look at the middle row. A command running inside a virtual machine with its own kernel, its own memory, and a hardware-enforced boundary costs 1.9 milliseconds more than the same command in a process jail. Not twice as much. Not an order of magnitude. Under two milliseconds.

Now look at the row above it. Creating that virtual machine costs 175 times more than creating the jail.

Where the cost actually lives

The expensive thing is not the wall. It is putting the wall up.

Once the machine is booted, the guest kernel is scheduled by the host like any other workload, and the virtualisation extensions your CPU has been shipping for fifteen years do the containment in hardware, at close to no cost. There is nothing to pay per operation, because nothing is being emulated or checked in software on the hot path.

This means the honest way to reason about isolation strength is not "how fast is this per command". It is: how many times will I cross the boundary, and how long will I stay once I am in?

A sandbox that boots once and then runs an agent for twenty minutes pays that 1.35 seconds exactly once, and then runs at process-jail speed for the rest of its life. A workload that creates and destroys a sandbox per operation pays it every time, and will feel terrible no matter what you do.

The consequence worth acting on

If almost all the cost is at the boundary, then the useful optimisation is not making execution faster — it is not paying for the boundary in the first place.

That is what snapshot restore is for. Restoring a running machine from a snapshot takes 5 milliseconds. Not booting it: restoring it, already warm, already past init, ready to take work. Three of those in parallel complete in under two seconds wall-clock, and most of that is copying disk, not starting machines.

So the shape of a fast sandbox fleet is not "use weaker isolation". It is: build the machine once, snapshot it, and clone. You get the hardware boundary and you skip the part that cost anything.

What this does not say

It does not say hardware isolation is free. A cold boot is still a second and a third, which is an eternity if a human is waiting, and a virtual machine still costs memory that a process jail does not.

It does not say the process jail is pointless. On a laptop, for a developer running one thing at a time, 7.7 milliseconds to create and 3.7 to execute is a genuinely different feeling to a second-plus.

What it says is narrower and more useful: the strength of the boundary is nearly free; only the act of building it is expensive. If you have been choosing weaker isolation to protect a hot path, measure it. The hot path was probably never the problem.