[x11] Provide ability to listen on UDS path. And disable wayland socket creation.

[ghost]

UDS x11 socket would save a redirection in some cases such as the rust-vmm VMM's that translate guest vsock into host UDS. Need to also be able to control the UDS path for this to work.

ex: --x-display=/path/to/firecracker/v.sock_9999 where guest x11 is forwarded via vsock to host.

Also for some reason a wayland socket is always created even when you don't want one. Omitting it attempts wayland-1. Can it be disabled?

[talex5]

It is possible to run the proxy on the host (to fix DPI scaling problems with X11 applications also running on the host), but forwarding X11 from a guest wouldn't be at all secure. main.ml:listen_x11 contains the current (abstract) listening address, and it should be easy enough to change it or add a non-abstract address if you want though.

You should be able to disable the Wayland socket fairly easily in main.ml - just don't call listen_wayland (the call to listen_x11 below it is already conditional).

[ghost]

Could you clarify why would wayland-proxy-virtwl handling a VM guest's x11 on an individual basis not be secure?

one wayland-proxy-virtwl instance per guest.

[talex5]

With one Xwayland per guest, it would be OK in theory, but it means moving a whole load of C code from the guest to the host. I don't see any benefit to doing that. You might as well do all the X11 stuff in the guest and just use Wayland to talk to the host.

Running X11 over vsock presumably means no shared memory, so performance would be worse too (though Wayland might not be much faster until #43 is implemented).

[ghost]

only crosvm is capable of efficiently sharing wayland between guest and host. if you use firecracker or cloud-hypervisor you have to use something like waypipe (also c code).

and currently wayland may not be entirely safe either, sway supports protocols which leak information without permission control

wayland-proxy-virtwl & xwayland may actually provide more isolation at this time. guest x11 windows will be isolated from each other and the host. I don't believe you allow x11 windows to interact with the wayland protocol in any way? something wayland applications will be capable of doing simply because they have access to the wayland socket.

[talex5]

only crosvm is capable of efficiently sharing wayland between guest and host. if you use firecracker or cloud-hypervisor you have to use something like waypipe (also c code).

@alyssais has been thinking about solutions for this: https://spectrum-os.org/lists/hyperkitty/list/discuss@spectrum-os.org/thread/5IN6OQ5ZV4Y3XWHKI2MNAVSL6ZGE5ERF/

and currently wayland may not be entirely safe either, sway supports protocols which leak information without permission control

Yes, you'd have to run another proxy on the host to deal with that (should be quite efficient, as it can just pass the handles to the shared memory to the compositor). But you need to do that anyway for native Wayland apps.

[voidastro4]

Is there no support for XCSECURITY (x11 security extension) ? If so, including it would be nice.