4 ms·

> The Qubes people don't recommend doing GPU passthrough because of the security implications. Why? DMA?

by 1996 6y ago

Nojlk 6y ago
I don't know details. I was thinking about doing GPU passthrough myself, but whenever developers chimed in on any posts about the topic, this is essentially what they said. Some links I remember going through: https://www.qubes-os.org/doc/device-handling-security/#pci-security https://www.qubes-os.org/doc/device-handling-security/#pci-s... > Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. You’re potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM’s ability to run a side channel attack and vulnerability to the same. See Xen PCI Passthrough: PV guests and PCI quirks and Software Attacks on Intel VT-d (page 7) for more details. https://security.stackexchange.com/questions/162122/gpu-passthrough-security/162175 https://security.stackexchange.com/questions/162122/gpu-pass...
fsflover 6y ago
"Clarifications on GPU security": https://groups.google.com/g/qubes-devel/c/MeLYpHyLRHQ https://groups.google.com/g/qubes-devel/c/MeLYpHyLRHQ See also: https://www.qubes-os.org/faq/#can-i-run-applications-like-games-which-require-hardware-acceleration https://www.qubes-os.org/faq/#can-i-run-applications-like-ga... But the fact is, even if you are doing GPI passthrough in Qubes, it's much more secure than running any other system.
gwd 6y ago
Basically, yes. Theoretically, all modern systems have IOMMUs, which are supposed to be able to allow an operating system (or hypervisor in this case) to restrict what a device can do. In practice, IOMMUs can't be trusted, for two reasons. First, the implementations (i.e., the actual hardware) are frequently full of unpatchable security holes. It's not just the CPUs themselves that need to be correct; every chip in the PCI chain has to DTRT from a security perspective or risk opening up a vulnerability. Secondly, particularly with GPUs, many systems have 'magic backdoors' that side-step the IOMMU systems completely. Frequently this is to make certain operations "faster" or "easier". Basically, unless you have done your own audit and testing of the hardware you own (or someone you trust has done the same thing), you have to more or less assume that a malicious guest with control of a physical device could break out of the system. In Xen's SUPPORT.md document, we very carefully tried to balance this: Because of hardware limitations (affecting any operating system or hypervisor), it is generally not safe to use [PCI passthrough] to expose a physical device to completely untrusted guests. However, this feature can still confer significant security benefit when used to remove drivers and backends from domain 0 (i.e., Driver Domains).

> The Qubes people don't recommend doing GPU passthrough because of the security implications. Why? DMA?

by 1996 6y ago

> The Qubes people don't recommend doing GPU passthrough because of the security implications. Why? DMA?

I don't know details. I was thinking about doing GPU passthrough myself, but whenever developers chimed in on any posts about the topic, this is essentially what they said. Some links I remember going through: https://www.qubes-os.org/doc/device-handling-security/#pci-security https://www.qubes-os.org/doc/device-handling-security/#pci-s... > Additionally, Qubes restricts the config-space a VM may use to communicate with a PCI device. Only whitelisted registers are accessible. However, some devices or applications require full PCI access. In these cases, the whole config-space may be allowed. You’re potentially weakening the device isolation, especially if your system is not equipped with a VT-d Interrupt Remapping unit. This increases the VM’s ability to run a side channel attack and vulnerability to the same. See Xen PCI Passthrough: PV guests and PCI quirks and Software Attacks on Intel VT-d (page 7) for more details. https://security.stackexchange.com/questions/162122/gpu-passthrough-security/162175 https://security.stackexchange.com/questions/162122/gpu-pass...

fsflover 6y ago

"Clarifications on GPU security": https://groups.google.com/g/qubes-devel/c/MeLYpHyLRHQ https://groups.google.com/g/qubes-devel/c/MeLYpHyLRHQ See also: https://www.qubes-os.org/faq/#can-i-run-applications-like-games-which-require-hardware-acceleration https://www.qubes-os.org/faq/#can-i-run-applications-like-ga... But the fact is, even if you are doing GPI passthrough in Qubes, it's much more secure than running any other system.

gwd 6y ago

Basically, yes. Theoretically, all modern systems have IOMMUs, which are supposed to be able to allow an operating system (or hypervisor in this case) to restrict what a device can do. In practice, IOMMUs can't be trusted, for two reasons. First, the implementations (i.e., the actual hardware) are frequently full of unpatchable security holes. It's not just the CPUs themselves that need to be correct; every chip in the PCI chain has to DTRT from a security perspective or risk opening up a vulnerability. Secondly, particularly with GPUs, many systems have 'magic backdoors' that side-step the IOMMU systems completely. Frequently this is to make certain operations "faster" or "easier". Basically, unless you have done your own audit and testing of the hardware you own (or someone you trust has done the same thing), you have to more or less assume that a malicious guest with control of a physical device could break out of the system. In Xen's SUPPORT.md document, we very carefully tried to balance this: Because of hardware limitations (affecting any operating system or hypervisor), it is generally not safe to use [PCI passthrough] to expose a physical device to completely untrusted guests. However, this feature can still confer significant security benefit when used to remove drivers and backends from domain 0 (i.e., Driver Domains).