logoalt Hacker News

Show HN: Sub-millisecond VM sandboxes using CoW memory forking

271 pointsby adammiribyanyesterday at 1:43 PM63 commentsview on HN

I wanted to see how fast an isolated code sandbox could start if I never had to boot a fresh VM.

So instead of launching a new microVM per execution, I boot Firecracker once with Python and numpy already loaded, then snapshot the full VM state. Every execution after that creates a new KVM VM backed by a `MAP_PRIVATE` mapping of the snapshot memory, so Linux gives me copy-on-write pages automatically.

That means each sandbox starts from an already-running Python process inside a real VM, runs the code, and exits.

These are real KVM VMs, not containers: separate guest kernel, separate guest memory, separate page tables. When a VM writes to memory, it gets a private copy of that page.

The hard part was not CoW itself. The hard part was resuming the snapshotted VM correctly.

Rust, Apache 2.0.


Comments

cpercivatoday at 2:14 AM

Don't forget about entropy! You've just created two identical copies of all of your random number generators, which could be very very bad for security.

The firecracker team wrote a very good paper about addressing this when they added snapshot support.

show 2 replies
injiduptoday at 7:19 AM

It's so frustrating seeing all this sandbox tooling pop up for linux but windows is soooooo far behind. I mean Windows Sandbox ( https://learn.microsoft.com/en-us/windows/security/applicati... ) doesn't even have customizable networking white lists. You can turn networking on or off but that's about as fine grained as it gets. So all of us still having to write desktop windows stuff are left without a good method of easily putting our agents in a blast proof box.

show 3 replies
BornaPtoday at 12:05 PM

Really impressive work. Sub-millisecond cold starts via CoW forking is a pretty clever approach.

The tricky part we keep running into with agent sandboxes is that code execution is just one piece, bcs agents also need file system access, memory, git, a pty, and a bunch of other tools all wired up and isolated together. That's where things get hairy fast.

crawshawtoday at 1:39 AM

Nice to see this work! I experimented with this for exe.dev before we launched. The VM itself worked really well, but there was a lot of setup to get the networking functioning. And in the end, our target are use cases that don't mind a ~1-second startup time, which meant doing a clean systemd start each time was easier.

That said, I have seen several use cases where people want a VM for something minimal, like a python interpreter, and this is absolutely the sort of approach they should be using. Lot of promise here, excited to see how far you can push it!

show 2 replies
aftbittoday at 2:35 PM

Is this a service or a library? The README has curl and an API key... Can I run this myself on my own hardware?

skwuwuyesterday at 3:32 PM

I noticed that you implemented a high-performance VM fork. However, to me, it seems like a general-purpose KVM project. Is there a reason why you say it is specialized for running AI agents?

show 1 reply
deividtoday at 8:34 AM

Niiiiiice, I've been working on something like this, but reducing linux boot time instead of snapshot restore time; obviously my solution doesn't work for heavy runtimes

polskibustoday at 2:54 PM

Is it possible to run minikube inside ? I’d love to use it for ephemeral clusters for testing .

indigodaddytoday at 2:05 AM

Your write-up made me think of:

https://codesandbox.io/blog/how-we-clone-a-running-vm-in-2-s...

Are there parallels?

quickrefiotoday at 3:29 PM

Feels like fork() but for VMs—very cool.

vmg12today at 1:12 AM

Does it only work with that specific version of firecracker and only with vms with 1 vcpu?

More than the sub ms startup time the 258kb of ram per VM is huge.

show 1 reply
indigodaddytoday at 2:08 AM

Does this need passthrough or might we be able to leverage PVM with it on a passthrough-less cloud VM/VPS?

show 1 reply
diptanutoday at 1:45 AM

The tricky part of doing this in production is cloning sandboxes across nodes. You would have to snapshot the resident memory, file system (or a CoW layer on top of the rootfs), move the data across nodes, etc.

show 3 replies
latortugatoday at 2:53 AM

Similar to sprites.dev?

theredsixtoday at 3:51 PM

super clever and awesome!

buckle8017today at 2:04 AM

This is how android processes work, but it's a security problem breaking some ASLR type things.

show 1 reply
aa-jvtoday at 1:26 PM

Nice.

Now I want the ability to freeze the VM cryogenically and move it to another machine automagically, defrosting and running as seamlessly as possible.

I know this is gonna happen soon enough, I've been waiting since the death of TandemOS for just this feature ..

yagizdagabakyesterday at 10:14 PM

Cool approach. Are you guys planning on creating a managed version?

show 2 replies
jauntywundrkindyesterday at 9:32 PM

I keep so so so many opencode windows going. I wish I had bought a better SSD, because I have so much swap space to support it all.

I keep thinking I need to see if CRIU (checkpoint restore in userspace) is going to work here. So I can put work down for longer time, be able to close & restore instances sort of on-demand.

I don't really love the idea of using VMs more, but I super love this project. Heck yes forking our processes/VMs.

show 2 replies
handfuloflighttoday at 12:45 AM

Can you run this in another sandbox? Not sure why you'd want to... but can you?

show 2 replies
justboy1987today at 4:42 AM

[dead]

olivercoleaitoday at 2:04 PM

[dead]

ydw0127today at 4:27 PM

[dead]

codancetoday at 2:15 AM

[dead]

jauntywundrkindtoday at 1:14 AM

Mods: can we merge with https://news.ycombinator.com/item?id=47412812?

show 1 reply
Jeffrin-devtoday at 5:59 AM

[flagged]

wei03288today at 6:28 AM

[flagged]

show 1 reply