<qyliss>
puck: know anything about virtio-wayland?
<puck>
qyliss: a little
<puck>
so there's apparently three ioctls added to the gpu, one connects to the host's compositor socket, and the other receives/sends messages
<puck>
and then you can also pass through file descriptors referencing GPU buffers (a la dmabuf), so you avoid the overhead of having to copy the window contents every time
<puck>
this works hand in hand with, it seems, virtio-gpu
<qyliss>
puck: do you know how the socket is exposed to the guest?
<qyliss>
IdleBot_51f8eb57: you might have discovered the answer to that too, actually. I imagine it's the same for any shared socket in crosvm.
<puck>
it's pretty cursed afaict
<puck>
qyliss: ioctl on the virtio gpu, DRM_IOCTL_VIRTGPU_WINSRV_{CONNECT,TX,RX}
<puck>
i am not sure exactly tho
<puck>
oh i see
<puck>
they changed this a while back
<puck>
qyliss: i presume it's vsock now
<qyliss>
That matches with what I've been able to found
<qyliss>
*find
<qyliss>
gods crosvm is so underdocumented
<puck>
duh, it's google :p
<qyliss>
I hear from ~sources~ they don't even have internal documentation
<puck>
qyliss: it *is* actually a custom protocol, but obvs only supported post 4.4, which is somehow the default version on the googlesource git
<puck>
so yeah, still same-ish protocol as i mentioned, magic ioctls
<Shell>
the VirtWL device from there seems to come from ChromeOS kernel patches
<Shell>
but idk whether it's been upstreamed?
<IdleBot_51f8eb57>
Soo, just to summarise: we want to run even local storage directories in a few special VMs because even through 9p there might be a stupid enough escape, but we are forced to run the most vulnerable thing in the entire modern computer — OpenGL — on host? Is there any perspective of VM-to-VM vsock?
<Shell>
ok, I give up trying to figure out wtf Google has done to this stack, none of it makes any sense
<Shell>
in theory, somewhere in Google's ChromiumOS kernel and *maybe* upstream, there's a file called virtio_wl.c which provides the device driver for the virtio-wayland stuff.
<Shell>
this can create a device /dev/wl0 which sommelier (and nothing else right now?) can use to obtain something to talk the Wayland protocol over to the host. separately, there's the usual virtio gpu stuff which is used for allocating gpu buffers/etc.
<qyliss>
IdleBot_51f8eb57: my goal is to run the Wayland compositor in a VM. I do not currently know the extent to which that is possible. Even if we ended up just connecting two sockets and relaying messages between them on the host, though, I think that would be pretty reasonable.
<qyliss>
Ultimately, there is nothing we can do (AFAIK) to counter GPU side channel attacks right now.
<qyliss>
Oh gods Sommelier uses gn
<Shell>
qyliss: I recommend peeling out the actual useful bits of it, it does lots of things for complicated ChromeOS-related reasons I think
<qyliss>
What sort of things?
<Shell>
something to do with multiple processes for some reason? I don't quite get it
<Shell>
also xwayland stuff I think
<qyliss>
Oh that bit
<IdleBot_51f8eb57>
Well, we also need cross-VM shared buffers, apparently?
<IdleBot_51f8eb57>
(sadly watching how VNC + VirtualGL slowly sounds more and more reasonable)
<IdleBot_51f8eb57>
A nice part about Xpra / VNCserver / whatever-like-that-for-wayland is that I can just disconnect-and-freeze the VM (if I choose to run Qemu, at least)
<IdleBot_51f8eb57>
Fun part: _I_ consider this a usability feature, but freezing everything that can touch GPU before connecting graphics to a high-security VM does sound nice security-wise…
<qyliss>
I'm not sure what it'd buy you
<qyliss>
Usually IIRC attacks can interfere before and after, not just during
<IdleBot_51f8eb57>
Well, cut-and-freeze means that I can just as well crash the current GPU-holding VM and launch a fresh one. Probably with some amount of GPU-RAM-nuking by allocating huge stupid stuff
<IdleBot_51f8eb57>
Leaking current VRAM has to be cheaper than full GPU takeover, right?
<IdleBot_51f8eb57>
(a lot of attacks-on-old-data use the fact that current VRAM != current screen content, see also selling old HDDs without full overwrite…)
<IdleBot_51f8eb57>
Or have I missed something really bad where reinitialising GPU and overwriting VRAM is still not enough?
IdleBot_51f8eb57 has quit [Remote host closed the connection]
IdleBot_5e50c57d has joined #spectrum
<Shell>
I really suspect that the realistic solution to that attack (where we assume the IOMMU works etc etc) is to attach a second cheap gpu and monitor to your machine, and just give the high-sec VM that whole device. I'm not super sure I'd trust a really complex layer of orchestrating freezing VMs, making the GPU forget its state properly, etc etc
<Shell>
(also the other VMs will probably be really upset if you restore them and all their GPU state is missing.)
<Shell>
and this all makes the assumption you actually give your low-sec VMs any real access to the GPU vs just being able to allocate buffers to be composited, and do software rendered opengl to that.
<IdleBot_5e50c57d>
Maybe most VMs should not have _any_ GPU state in the first place (Most of my Firefox instances run on Mesa… and they survive)
<Shell>
mhm
<qyliss>
> ERROR at the command-line "--args":1:12: Invalid token.
<qyliss>
> I have no idea what this is.
<qyliss>
Ah, gn
<IdleBot_5e50c57d>
Well, given that CPUs have unbounded number of side-channels exploitable directly from very high-level languages, and given that I fully expect GPUs to be worse than CPUs in _everything_, it would be nice to be able to reinitialise GPU from time to time just in case. Forget security, just to avoid bug accumulation!
<Shell>
the big thing is doing things like e.g. watching downloaded videos. you probably want to render to GPU, might even want some acceleration, but also your data source isn't super trustworthy, and you might wind up sharing the gpu with a high-sec VM, which probably isn't great.
<Shell>
although probably still needs a couple more vulnerabilities to actually get interesting data anywhere.
<IdleBot_5e50c57d>
I wonder, can we have constant-time FBTerm version?
<Shell>
qyliss: do you have the right kernel stuff to get sommelier working against?
<qyliss>
I'm trying to get it to build first
<qyliss>
And I can already tell that this is going to be a nightmare
<Shell>
:(
<IdleBot_5e50c57d>
Hmmm, maybe it is not that hard to actually run more stuff in fbterm only switching to X for Firefox (with status line integration so that I know when I want to switch)
<Shell>
IdleBot_5e50c57d: btw, cross-VM vsocks are a thing apparently, although I'm guessing they don't exist in crosvm
<IdleBot_5e50c57d>
Hard part: external monitor connected to the laptop…
<Shell>
and virtio-wayland doesn't seem to be built on top of vsock anyway(?)
<qyliss>
Shell: it is as far as puck and I can tell I think?
<Shell>
weird
<Shell>
qyliss: so sommelier is built on top of a kernel module that presents a /dev/wl0 device that seems to have nothing to do with vsock directly, but maybe the kernel module uses vsock? I've still not actually found it :/
<lejonet>
Cool! as I said, there isn't any thing inherently technical that would hinder it, and perhaps the host<->guest usage is simply just the only way I've seen it being used
<qyliss>
So many levels of this to understand, though
<lejonet>
indeed, its not a simple subsystem
<qyliss>
Seems like I need to develop a really solid understanding of virtio, and then figure out how to map that to crosvm, if it's even possible.
<lejonet>
sounds sane, especially if you're going to leave much of the heavy lifting to virtio (if possible)
<qyliss>
But I have no idea how to goe about doing that
<lejonet>
The heavy lifting or understanding virtio?
<qyliss>
Understanding virtio
<lejonet>
and I can't be much of help, I've only ever used virtio as a end-user
<lejonet>
that paper seems like a fairly good start tho :P
<qyliss>
that's what I'm doing tomorrow, then, I gues