zlacker

[parent] [thread] 9 comments
1. redtue+(OP)[view] [source] 2016-03-10 22:45:25
Does anyone know if PCI passthrough works so we can play games inside a windows vm? Some user already asked this on the mailing list but got no answer. [1]

[1] https://groups.google.com/forum/#!topic/qubes-devel/MfHy2jmX...

replies(2): >>wtalli+21 >>newman+X9
2. wtalli+21[view] [source] 2016-03-10 22:57:54
>>redtue+(OP)
Qubes uses Xen and thus PCI passthrough for gaming can be made to work through the same procedures necessary for any other Xen+Linux OS.

But PCI passthrough for gaming isn't a great fit for the Qubes security model: it requires trusting that the Windows guest cannot compromise the GPU you loan it, which makes it a much bigger risk than an ordinary AppVM.

replies(2): >>redtue+e3 >>zurn+Ms
◧◩
3. redtue+e3[view] [source] [discussion] 2016-03-10 23:20:07
>>wtalli+21
Thanks for the answer, that's promising. Maybe I give it a try after investigating if my other hardware is supported (vt-d etc. is no problem, but it's not on the supported hardware list).

Yes, a dedicated machine for gaming would certainly be better. But I play only irregularly and games like Divinity: Original Sin, Pillars of Eternity etc. which I kind of trust to don't hijack the GPU.

replies(1): >>heaven+9j
4. newman+X9[view] [source] 2016-03-11 00:37:58
>>redtue+(OP)
Lol. I was trying to see if I could go this to work under VMware a few years ago but never go anywhere.
replies(1): >>SXX+CA
◧◩◪
5. heaven+9j[view] [source] [discussion] 2016-03-11 02:48:27
>>redtue+e3
It's not exactly about trusting the game. You'd be extending trust to... everything inside the VM you expose the graphics card to.

And graphics cards are messy. Many of them are frankly a lot like accessing main memory without an MMU. It's extremely easy to get scrapes of other application's video RAM that hasn't been zeroed.

I'm not trying to tell you you shouldn't do it of course. Just... be aware. "hijack the GPU" doesn't even require a whole lot of malice. I've had video memory of my firefox tabs from last shutdown draped across my screen while the lightdm login windows do their first paint, for example. This is just the world we live in :(

replies(1): >>redtue+VK5
◧◩
6. zurn+Ms[view] [source] [discussion] 2016-03-11 06:02:47
>>wtalli+21
I thought the PCI passthrough security model assumes that the guest does compromise the GPU, and the guest-controlled GPU is isolated from the rest of the system using the IOMMU.

Do you mean these controls are porous by design or are you talking about bugs in the IOMMU protections?

replies(1): >>SXX+mA
◧◩◪
7. SXX+mA[view] [source] [discussion] 2016-03-11 08:15:23
>>zurn+Ms
First of all guest can easily update firmware on that device. As stated before GPUs are really complex devices and some part of them might be badly documented, like there is whole HDCP / DRM support that isn't documented at all. Of something like that happen you'll never find out.

Next time your PC going to boot your GPU will be initialized with host BIOS / UEFI long before kernel get possibility to limit it with IOMMU.

replies(1): >>zurn+8d2
◧◩
8. SXX+CA[view] [source] [discussion] 2016-03-11 08:20:01
>>newman+X9
Just in case PCI(e) passthrough working perfectly on Linux with KVM and Xen for years with QEMU.
◧◩◪◨
9. zurn+8d2[view] [source] [discussion] 2016-03-12 06:27:11
>>SXX+mA
Interesting point. I hope this threat is something GPU vendors address, since secure virtualized GPU access has been a marketed feature for a while (at least from AMD). Quick googling drew a blank sadly.
◧◩◪◨
10. redtue+VK5[view] [source] [discussion] 2016-03-14 20:16:54
>>heaven+9j
I remember reading a submission here on hn about the problems with GPUs a while back.

No worries, I did not undertand it that way. I like it if users try to keep the awareness about potential security problems up.

[go to top]