to handle 9P over vsock, but I haven't tested yet. We can use existing virtiofsd and 9P software (there are promising Rust implementations of each), and harden them against potential vulnerabilites like directory traversals using kernel features like RESOLVE_BENEATH and RESOLVE_NO_XDEV. For the boot device, maybe there's no reason not to
Also, if the server is in a namespace seeing only a bind mount to the necessary part of the FS, in a VM that only sees that one FS, the cheap attacks just become moot. You can probably talk it into traversal, but it doesn't see more than allowed anyway; talking it into attacking the VM kernel is hopefully harder (and still has limited impact)
just mount it using the host kernel, or maybe there's something to be gained by just reading a small bootstrap payload into memory from the start of the disk once, and then making all future communication go via a VM. I'm not really sure yet. But the important thing is we'll have mechanisms for all this in place. Maybe we'll decide that non-boot devices should just go over inter-VM 9P, but in any case, we'll still need all these pieces.
Can virtiofs eventually be backed by a VM-wrapped vhost-user?
Although we probably do want host-side page cache, as VM's requests to host are way more transparent for the scheduler than inter-VM requests.
computers I've tried it on so far. I suspect that I will get GPU isolation working, but I'm not sure how reliable or performant it will be.
Hmm. Also a good question what is the timeslice for inter-VM communication. Does it make sense to have two VMs alternate for slices of ten milliseconds? This is just what is probably needed to have 25fps video playback���
I'm pushing quite hard to make it over the line with my hardware isolation funding milestone. I'm so close, and I'm about to need the money. But once I've hit that, I think I'm going to need a break. This stuff is gruelling.
I wish you strength for this push!