Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 85 posts

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

#21

Post by indigodaddy »

jauntywundrkind wrote: post #4

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 o…

You could throw this on a VPS or server and it could help in that regard: (disclaimer, my thing)

https://GitHub.com/jgbrwn/vibebin

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

#22

Post by cperciva »

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.

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

#26

Post by Retr0id »

cperciva wrote: post #22

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.

I suppose it'd be easy enough to re-seed RNGs, but re-relocating ASLR sounds like a pain. (Although I suppose for Python that doesn't matter)

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

#28

Post by hinkley »

Retr0id wrote: post #26
cperciva wrote: post #22

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.

I suppose it'd be easy enough to re-seed RNGs, but re-relocating ASLR sounds like a pain. (Although I suppose for Python that doesn't matter)

Off the cuff, the first step to ASLR is don’t publish your images and to rotate your snapshots regularly.

The old fastCGI trick is to buffer the forking by idling a half a dozen or ten copies of the process and initialize new instances in the background while the existing pool is servicing new requests. By my count we are reinventing fastCGI for at least the fourth time.

Long running tasks are less sensitive to the startup delays because we care a lot about a 4 second task taking an extra five seconds and we care much less about a 1 minute task taking 1:05. It amortizes out even in Little’s Law.

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

#29

Post by edunteman »

indigodaddy wrote: post #18
crawshaw wrote: post #14

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 pyt…

simonw seems like he's always wanting what you describe, maybe more for wasm though

I’ve been a big fan of “what’s the thinnest this could be” interpretations of sandboxes. This is a great example of that. On the other end of the spectrum there’s just-bash from the Vercel folks.

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

#30

Post by cperciva »

Retr0id wrote: post #26
cperciva wrote: post #22

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.

I suppose it'd be easy enough to re-seed RNGs, but re-relocating ASLR sounds like a pain. (Although I suppose for Python that doesn't matter)

Re-seeding is easy. The hard parts are (a) finding everything which needs to be reseeded -- not just explicit RNGs but also things like keys used to pick outgoing port numbers in a pseudorandom order -- and (b) making sure that all the relevant code becomes aware that it was just forked -- not necessarily trivial given that there's no standard "you just got restarted from a snapshot" signal in UNIX.
Post reply on HN