<MichaelRaskin>
qyliss: I guess there are multiple optional layers if you don't want to trust Wayland implementations. https://github.com/whitequark/rust-vnc for isolating stuff causing too much panic, I dunno
<MichaelRaskin>
O-o-o-o-kaaaay… «failed to initialize syslog: guess of fd for syslog connection was invalid»
<MichaelRaskin>
(I indeed do not have syslog or anything similar running on my system)
<MichaelRaskin>
For the record, talking to system-wide syslog is not the first thing I want a maximally-isolated VMM to do!
<qyliss>
Important to remember that this is Chrome OS's hypervisor, and its defaults will be tailored toward whatever makes sense for Chrome OS.
<qyliss>
The issue I've had is that I can't get it to find a root file system
<qyliss>
An initrd works, but just pointing it to a rootfs with -r doesn't
<qyliss>
at least for me
<qyliss>
suspect I'll be doing something wrong with my kernel, but I am definitely compiling in SquashFS
<MichaelRaskin>
Are we ever going to use materialised rootfs?
<qyliss>
What do you mean by materialized?
<MichaelRaskin>
As opposed to 9P-supplied
<MichaelRaskin>
(or whatever we end up using)
<qyliss>
Ah, right.
<MichaelRaskin>
I considered looking for CrosVM forks, but I cannot invent a good enough search term…
<qyliss>
Look up rust-vmm
<qyliss>
That's oracle and amazon and google's joint effort for Rust hypervisors
<qyliss>
Which in practice means derivatives of crosvm
<qyliss>
But I don't think there's much out there beyond Firecracker
<qyliss>
I doubt whatever Oracle has would get us anything
<MichaelRaskin>
Well, from Rust-VMM page it is not even obvious Oracle does anything
<qyliss>
Don't remember where I read that then
<qyliss>
Oh maybe I confused Oracle with Inter
<qyliss>
*Intel
<MichaelRaskin>
Then there is Alibaba and Red Hat
<MichaelRaskin>
Kind of unclear whether the listed teams have their own forks…
<qyliss>
But I doubt any others are really going for the desktop virtualization niche of crosvm
<qyliss>
crosvm's 9p support looks like it might need some work from us
<qyliss>
It does 9p, but only exposes it as shared directories between host and guest
<qyliss>
as far as I have so far managed to discern
<MichaelRaskin>
Well, if the directory is read-only-for-VM on host and also bind-mounted-as-RO inside VM, what is the problem?
<qyliss>
Risk of directory traversal, no?
<qyliss>
Wasn't that what we talked about before with jpo?
<MichaelRaskin>
That's one I want to contain VM.
<MichaelRaskin>
Directory traversal outside the shared directories is still a bug in the VM, and a slong as it is not a breakout, container around VM should make it useless
<qyliss>
<jpo> if we expose the network stack and filesystem of the host, i guarantee that'll eventually lead to an escape
<qyliss>
I tihnk we're just setting ourselves up for vulnerability chaining with this
<qyliss>
Once you find a VM escape, you just keep it to yourself until the next container escape comes along
<qyliss>
And then you can break out
<qyliss>
But if the 9p server never interacted with the host fs at all, the scope for there ever being a breakout is smaller
<MichaelRaskin>
In that case you don't even care about VM support for 9P
<qyliss>
That's true, actually.
<qyliss>
Good point.
<MichaelRaskin>
You do care how to proxy all this networking with minimum amount of RAM-copies
<MichaelRaskin>
Of course, this means too many hops for mmap to work well…
<qyliss>
I guess for now I can go ahead with whatever 9p server, and replace it with a filesystem-independent one later
<qyliss>
And network performance and resource usage can also be iterated on
<MichaelRaskin>
It would be funny if using Git at all would require RW block device passing
pie_ has quit [Remote host closed the connection]
<qyliss>
rootfs on 9p is going to be fun...
pie_ has joined #spectrum
<qyliss>
I hope I can actually get that to work
<qyliss>
Would be much cooler than using an initrd
<MichaelRaskin>
Wait, you want _straight_ to 9P rootfs, without initramfs to set this up?
<qyliss>
Why not?
<puck>
qyliss: i have done so, iirc? or well, /nix/store on 9p, and / on tmpfs
<puck>
actually does nix's build-vm even use an initramfs
<puck>
yes
<MichaelRaskin>
I guess NixOS build-vm wants to use Hydra-built kernel
tilpner has joined #spectrum
Thierry64 has joined #spectrum
<MichaelRaskin>
Pity, syslogng cannot use an alternative socket name
<pie_>
time for patches
<qyliss>
I don't necessarily expect to use crosvm unmodified, fwiw.
<qyliss>
Our interests and Chrome OS's interests won't line up perfectly.
<qyliss>
But we'll see.
<MichaelRaskin>
Hmmm
<MichaelRaskin>
Is 9p support in crosvm too new to get into any stable release?
<MichaelRaskin>
Ah no sorry, just weird naming
<MichaelRaskin>
Ouch ouch ouch. Virtio-FS (like FUSE but for VMs): Guests sharing a file system must trust each other
<Shell>
is that a thing of "someone could put a setuid executable in the filesystem" or something else?
<MichaelRaskin>
Current implementation has UID/GID checks only on the client
<Shell>
I don't see another way to do it that gains you any security? the VM kernel can claim to be whatever UID it wants
<Shell>
(short of doing Kerberos auth or something a la NFSv4)
<MichaelRaskin>
One could have some policy in the VM-side daemon that some UIDs just won't be believed
<MichaelRaskin>
Hmm. CrosVM 9p and NixOS 9p mounting don't like each other
<MichaelRaskin>
And of course CrosVM wants a TAP FD
infinisil has joined #spectrum
<MichaelRaskin>
Apparently, CrosVM lacks any network support that can be established without root access, even just VM-to-VM?