gVisor is open-source, and `cuda-checkpoint` is freely available.
gVisor's `runsc checkpoint` subcommand supports a `--save-restore-exec-argv` which lets you specify a program to execute before gVisor starts taking the process snapshot.
Ah, I see the distinction. In my case, I was using the PulseAudio client+server with a network sink running in-sandbox, producing a set of audio samples that are then replayed by a PulseAudio client in the out-of-sandbox Rust application receiving these samples. Exposing the socket directly to the sandbox is dangerous, e.g. it would let the sandbox record the host's microphone directly.
My goal was for the sandbox to only have access to a single dumb playback sink and no other access by default, and to gate any further access (e.g. microphone access) in something the out-of-sandbox software can catch and ask the user about before it is granted to the sandbox.
That's the approach I initially took, but experienced some combination of noticeable stuttering and latency regardless of which buffering strategy I tried... Had to switch to a shared memory ring buffer, along with some adaptive playback speed shenanigans (sometimes imperceptibly speeding up playback when falling behind production of audio samples, sometimes imperceptibly slowing down when there's less than a few milliseconds' worth of samples left in the ringbuffer), in order to achieve actually-gapless playback.
Thanks. We're working on rootless network setup to make `runsc do --rootless` work with networking enabled when `passt` is installed right now. See issue #13337 (yes that's a cool issue number) which should unblock this.
The tty issue is known, should be fixed soon too, though contributions welcome as it sounds like it should be simple fix and we love more contributions :)
FWIW, X11 apps work well, I have a personal hacky project in which I've been running Librewolf in gVisor, with the window being reflected as a native Wayland window. It uses `Xvfb -fbdir` aimed at a bound tmpfs mount to get a shared memory region containing the window's pixel data which can be read directly from out of the sandbox, has Pulseaudio audio passthrough, and a socket server passing through mouse/keyboard events to make the window interactive. Works smoothly even for YouTube playback, and I successfully played a game of Unreal Tournament 2004 at 24fps in it, with no noticeable mouse/keyboard latency :)
We're basically making baby steps to get there less hackily.
Any reason why you wouldn't use gVisor's bwrap interface yet? We're working on it precisely to make DIY sandboxing on Linux as easy as possible in order to get Linux-sandboxing-at-home to mature beyond the current syscall-filter-and-namespaces duct tape stage, so I'm curious to know what you'd like to see.
gVisor's `runsc checkpoint` subcommand supports a `--save-restore-exec-argv` which lets you specify a program to execute before gVisor starts taking the process snapshot.
You can fill in the blanks from there.