26 Aug
2020
26 Aug
'20
1:31 p.m.
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!