Since with sys-gui-gpu, gpu is isolated from dom0, what would be the reason not to allow gpu acceleration to all the qubes to which sys-gui-gpu is guivm?
All the non-dom0 qubes are by default already considered as compromised, so sys-gui-gpu then is too?
So I imagine a case where the Windows qube is much safer to run in sys-gui-gpu with full acceleration, then without it in dom0?
This is especially for cases where for these purposes dGPU can be used on external monitor, while sensitive operation can be done in dom0 on iGPU and with qubes to which dom0 is set as guivm.
A bit off-topic, but now I am realizing how would even be possible to isolate dom0 from all gpus? Sys-gui-gpu on iGPU then to login to it then another sys-gui-gpu nested for dGPU? Sounds weird.
GPU virtualization, I think. You need a safe way for qubes to share the graphics memory in a compartmentalized way, the same way it is done for the CPU.
All the non-dom0 qubes are by default already considered as compromised,
If that was true, then only dom0 would be usable for data processing.
This is especially for cases where for these purposes dGPU can be used on external monitor, while sensitive operation can be done in dom0 on iGPU and with qubes to which dom0 is set as guivm.
But these are separate hardware components, each with its own memory.
From what I understand, sys-gui-gpu would have all of the gpus. Both igpu and dgpu if it exists. The desktop, and the login would be done through sys-gui-gpu.
It wouldn’t change anything about getting gpu acceleration in windows as that does not use wayland. Windows would still require a gpu passed to it to get gpu acceleration.
You wouldn’t expect to be able to plug a PCI device (the GPU) into multiple physical machines with some sort of splitter cable and use it concurrently like that, right? Similarly for virtual machines. A much more sophisticated mechanism needs to be there to make sharing work at all. And it still needs to be secure even if dom0 isn’t involved, so that VMs with access to the shared GPU can not spy on or tamper with each other’s content.
If you don’t need isolation between some VMs, then they usually don’t need to be separate VMs at all. Merge their stuff into one big VM, and pass a GPU through to that VM for its exclusive use.
But sometimes, there are things that work only in Windows, some only in Debian, some in Kali, and each of them needs GPU acc… and the one might want/need to use them in parallel, not one at the time…
I am not advocating, I am genuinely trying to understand security drawbacks I am not aware of, for my threat model.
Then you still need a mechanism to make the sharing work at all. With such heterogeneous systems, that probably rules out every mechanism except for proper GPU virtualization support in Xen.
I am using this concept here to share GPU with other qubes. It works great but has a memory leak when browsing, causing a restart to be necessary when the memory runs full. Otherwise it works fine with my Intel iGPU.
Thanks, I just had that great topic on my mind inspiring me to start this one.
It is valuable resource, already bookmarked in my notes before I started this topic.
What I was trying with my topic was to perceive, anticipate security drawbacks I am not aware of, as well as eventually to check what are the odds we to be given with such an option when creating sys-gui-gpu (by customizing Saltstack formulas, or anyhow).
You don’t just “share” the GPU. You share graphics memory too and sharing (without limits) is contrary to compartmentalizing (Qubes approach).
Example:
Suppose you have your sys-gui-gpu without restrictions, so that any qube can read/write to graphics memory and can use all advantages of graphics caching etc.
Qube A: your banking qube
Qube B: your online gaming qube
You decide to access your bank account in A while your B is on too, so you display your bank account details in a web interface. Qube B reads that memory without restrictions - Bada Bing! All that remains is that B takes a screenshot and sends it somewhere.
Additionally, unlimited GPU sharing would mean anything you type in any qube (dom0 included) will be visible to other qubes.
I am always very well aware of the most of security threats, constantly looking for new ones I am not aware of.
But thanks, sincerely. I have no doubt some will come up at some point, and hopefully at the end we will get an option to run sys-gui-gpu as described in OP
