Hybrid mode GUI domain - without real GPU passthrough

[marmarek]

ITSTM we can attempt to create the first version of GUI domain without the need to have a GPU passthorugh working (which itself is a complex topic). This is the sketch of the idea (for Qubes 4.x):

1. Designate one of the AppVMs as "GuiDom". Allow GuiDom to run as full screen.
2. Run a full screen Xephyr there as the only application shown on the real screen by gui-daemon in dom0.
3. Run only a very minimal window manager in Dom0. In theory only to display the GuiDom window, in practice we might want it to be able to handle some hot keys and open a terminal window (e.g. when Qubes booted in "debug" or "admin" mode). Do not provide trusted decorations.
4. Run one of the normal Qubes-aware window managers in GuiDom, e.g. Xfce4 with Qubes customization. Connect it to the Xephyr server, not X server with a dummy driver.
5. Run gui-daemons (guids) in the GuiDom, and have other VMs connect to these GuiDom's guids.

Pros:

1. Ability to lock down the user. I.e. the user has no full admin access (no full access to Dom0), only a limited access as allowed by our management policy (which is coming in Qubes 4.0). This is considered a required functionality for any business/corporate deployment of Qubes OS,
2. Isolation of the whole Desktop Environment software stack from Dom0,
3. Provides a smooth way to switch to "true GuiDom" (i.e. one with full GPU pass-through) in the future.

Cons:

1. No GPU acceleration for the (effective) window manager, e.g. no nice eye candy effects. But we already don't have much of these in Xfce4... (but maybe shadows will be no longer?)
2. No isolation of (potentially compromised) GPU device (but we don't have that now anyway).

The #1 will be a regression from the present state (GuiDom = Dom0). It will be fixed by switching to a true GuiDom later. Meanwhile we can offer this feature as an opt-in during installation.

Of course this all requires ability to run e.g. Qubes Manager and qvm-tools in GuiDom and have control over what these management tools can and cannot do. And this is exactly what our shiny new exciting Qubes API Management will allow in 4.0 :)

Originally posted by @rootkovska in #833 (comment)
(adjusted description to the simplified version)

[pwmarcz]

Screenshot from R4.1: sys-gui as a Xephyr window, showing windows for VMs for which it is the designated GuiVM. It also shows RPC confirmation prompts and notifications (#3904) for calls originating from these VMs.

[marmarek]

This all can be installed using salt (in recent R4.1 version):

sudo qubesctl top.enable qvm.sys-gui
sudo qubesctl top.enable qvm.sys-gui pillar=True
sudo qubesctl --all state.highstate
sudo qubesctl top.disable qvm.sys-gui

This will create sys-gui VM, which can be set as global default-guivm or a guivm for selected VMs only (use qubes-prefs and qvm-prefs respectively).
Note this is still highly experimental feature.

[92VV3M42d3v8]

Is it planned to provide sys-gui by default like sys-net or its going to be just user installable. BTW I tried this and 3rd command failed with qubesctl error no such option --all. I will install build today posted on openqa and report back.
Edit: Global default is set but any VM will start and no GUI will be there in latest testing build. Can anyone try to set it as default GuiVM so issue can be reproduced. If you want @marmarek, I can reproduce and provide logs. Let me know which logs may be needed. BTW the issue seems to be related to some packages missing from fedora-32-xfce template.

[marmarek]

Is it planned to provide sys-gui by default like sys-net

No, see https://www.qubes-os.org/news/2020/03/18/gui-domain/#what-will-actually-be-in-qubes-41 for the plans.

failed with qubesctl error no such option --al

Ah, indeed I placed --all in the wrong position. I've updated the comment.

[andrewdavidwong]

Qubes user panati tested this and reported the experience in this thread:

https://qubes-os.discourse.group/t/missing-packages-in-fedora-32-xfce/619/

[DemiMarie]

This now works.