qyliss changed the topic of #spectrum to: A compartmentalized operating system | https://spectrum-os.org/ | Logs: https://logs.spectrum-os.org/spectrum/
erictapen has joined #spectrum
erictapen has quit [Ping timeout: 240 seconds]
klltkr has joined #spectrum
klltkr has quit [Ping timeout: 256 seconds]
nicooo has quit [Remote host closed the connection]
nicooo has joined #spectrum
cole-h has quit [Ping timeout: 260 seconds]
<qyliss> Today's objective: figure out what needs to happen in a guest to make something that looks like a socket from the /dev/wl0 interface exposed by the virtio_wl kernel driver.
<qyliss> CrOS might already have something for this. If not it can probably be extracted from Sommelier.
klltkr has joined #spectrum
<qyliss> puck: do you know anything about the above? I'm wondering about virtwl_guest_proxy...
<qyliss> They keep alluding to other protocols using virtio wayland, but I'm not sure what those actually are
<puck> hrm, so
<puck> oh, interesting
<puck> so. virtwl_guest_proxy sets up a unix domain socket, and redirects sendmsg() and recvmsg() to VIRTWL_IOCTL_SEND and VIRTWL_IOCTL_RECV
<puck> i believe, at least
<qyliss> I wonder if virtwl_guest_proxy is used anywhere in CrOS
<qyliss> It looks kinda dead
<puck> yes
<puck> maitred
<qyliss> Oh interesting
<puck> so maitred runs inside the VM, but not in the container
<puck> and sommelier runs inside the container
<puck> so it goes [sommelier -> virtwl_guest_proxy] -> crosvm?
<qyliss> But Sommelier does its own ioctls?
<puck> yeah, that's the weird part
<qyliss> Isn't /dev/wl0 just passed into the container?
<puck> you can have >1 container, at least..
<puck> oh yeah indeed
<puck> > Sommelier has taken over this duty now.
<puck> so yeah, virtwl_guest_proxy is dead
<puck> if you want to virtualise a /dev/wl0 interface, you probably need to use something like FUSE
<puck> maybe.
<qyliss> Nah, what I want to do here is to just use virtio_wl as a transport for a different fd-using protocl
<qyliss> Specifically VmMemoryControl from crosvm, but that doesn't really matter.
<qyliss> I suppose what I'll want to do is write a socket-like Rust type that does the appropriate ioctls instead of actually writing to a socket?
<puck> oh, that'd be very fancy
<qyliss> Alternatively, I could just try to use virtwl_guest_proxy, and hook up the existing Rust code to the socket it exposes
<qyliss> I'm not really sure which is better
<qyliss> The ioctl approach doesn't look as complicated as I was expecting.
<puck> mhm, it's not too hard, it's just a fancy sendmsg / recvmsg
<puck> i'm not sure what the limits are on FDs you can transfer tho
<puck> it's not arbitrary
<qyliss> All I'm interested in is memfd
<qyliss> (Or mmap, ofc)
<qyliss> Presumably Wayland uses one of those already?
<puck> i believe memfd works
<qyliss> sweet
<puck> at least, sommelier uses those, right?
<puck> i haven't looked at the kernel bits too much
<qyliss> I think it must do but I'm not really sure
<qyliss> I guess I'll find out
<qyliss> Thanks for the help!
<puck> i think it might require dmabuf or (dmabuf over) virtwl.. so doing the mmap is more complicated, i think
<qyliss> What's "it" in that sentence?
<puck> shared memory over virtio-wayland
<puck> oh actually
<puck> see virtwl_ioctl_new_type in virtwl.h
<puck> i'm not very smart and it seems you can transfer pretty varied things over the connection
<qyliss> VIRTWL_IOCTL_NEW_ALLOC looks pretty promising :)
<puck> you can create readable pipes, writeable pipes, and memory buffers
<puck> note that you cannot pass external file descriptors into this thing
<puck> afaict
<qyliss> that's fine
<qyliss> I tihnk
<qyliss> virtwl_guest_proxy seems to accept file descriptors, though?
<qyliss> at least, it uses recvmsg
<puck> .. good point.
<puck> hrmm
<qyliss> Looks like virtwl_guest_proxy assumes those are always pipes
<qyliss> But I'm not sure if that's an actual protocol/kernel-imposed limitation.
<puck> errrrrr so
<puck> don't pass in arbitrary FDs, this may be a safety hazard
<qyliss> okay, fun
<puck> virtio_wl does anon_inode_getfd(), which sets the private_data of the struct file, which is then returned (as fd)
<puck> if you create a new resource file descriptor, that is
<puck> in virtwl_vfd_send, it translates the FDs back to struct file, and then checks their private_data. but private_data is also set if you open e.g. a tty
<puck> it then sends these vfds over to the host, i think
<puck> hrm, VIRTWL_IOCTL_NEW_CTX is probably an actual wayland socket on the server side usually, and is probably implicitly connected
<qyliss> So are you saying that putting an arbitrary fd into virtio_wl will mess with private_data, which might also be used elsewhereL
<puck> it won't mess with it, but it'll try to read any, even if it's not its own
<qyliss> Oh I see
<qyliss> right yeah it assumes private_data is a struct virtwl_vfd
<qyliss> that's rude
<qyliss> (a pointer to struct virtwl_vfd)
<qyliss> puck: doesn't virtwl_vfd_send check if a file descriptor is a virtwl one before it looks at its private_data?
<qyliss> if (vfd_file.file->f_op == &virtwl_vfd_fops) {
<puck> oh, oops
<puck> oh, am i looking at the wrong kernel branch thing
<puck> it does now, but only works with virtio-gpu dmabufs i think?
<qyliss> It does some stuff in the else even if gpu stuff is disabled
<puck> it decrements the fd's refcount, sets the error to -EINVAL, then does the things again
<puck> so it just ends up returning -EINVAL
<qyliss> ah, right
<qyliss> So that just stops you putting arbitrary fds into it?
<qyliss> So I think that means the only file descriptors you can put into virtio_wl are ones that came out of it in the first place?
<qyliss> (Or some gpu thing)
<puck> yeah
<qyliss> Oh, and what virtwl_guest_proxy actually does is make a virtio_wl pipe, and then proxy it to the actual pipe that was given to it
<qyliss> That makes more sense
<qyliss> So I'd have to change VmMemoryRequest to not include an fd, and instead include an fd in the response...
<qyliss> Not quite what I was hoping for, but potentially better than no fds at all...
pie_ is now known as pie_[bnc]
erictapen has joined #spectrum
erictapen has quit [Ping timeout: 256 seconds]
erictapen has joined #spectrum
klltkr has quit [Read error: Connection reset by peer]
cole-h has joined #spectrum
danielrf[m] has joined #spectrum
erictapen has quit [Ping timeout: 256 seconds]
klltkr has joined #spectrum
klltkr has quit [Ping timeout: 264 seconds]