Are the security issues posed by GPU-Passthrough under or over exaggerated?

I am trying for the life of me to create a linux + windows computer as a daily driver with hardware acceleration for both. However, with the security concerns over pcie passthrough it seems I will be settling on vmware workstation (seeing as allows for hardware acceleration without passthrough)

Are the security vulnerabilities of gpu-passthrough mostly negligible, or is it just there are no other options? Are the security concerns mainly from using the iommu acs patch? Are there vulnerabilities other than ROM modifications ?

PS:
I am a near laymen when it comes to the inner workings of PCIE.
Iv’e tried vgpu_gpu unlock, but I am uncertain about the projects longevity.
the open vfio project still seems to be having compatability issues; so Im still steering clear of that as well.

Thank you!

What sort of threat scenario do you have?
Unless you got a PAP-Firewall setup, hardened all your software installations and got all sorts of network-based attacks mitigated, then I would not worry about someone exploiting some hardware/driver exploit.

Intel Management Engine in combination with Spectre and Meltdown-style attacks would be a much bigger concern.

3 Likes

So we’re on the same page, this is all extremely unlikely as well and really only a concern if you’re literally sharing the machine with an attacker, right? Or did I miss something new?

Breaking out of sandboxes and VMs is going to get worse in the future, and random black-boxes with higher than Ring 0 privileges are also going to get worse.

AFAIK malicious Javascript has been used to exploit some of those vulnerabilities in the wild.

Right but in most cases these are realistic threats only where you have other “tenants” using VMs on the same host (or the attacker has access to host itself). If this is a home lab situation the probability of such an attack must approach zero…? Or am I wrong? I am looking into ME/vPro right now because I think the whole SOL thing is neat (basically IPMI for free!). Now you have me wondering if I’ve missed something.

Like I initially stated, define your threat model.
Running something with a webinterface open to the internet is inviting people to do bad things, having your friends VPN in for some collaborative gaming is safe-ish, isolating your crown-jewels using elaborate PAP-firewall schemes and proxies is reaching for gold.

Just keep in mind Javascript is dangerous and side-channel exploits have practical uses, so even your ordinary browsing may be better suited to the “resets on shutdown”-terminal box, depending on what you are doing. In other words, how paranoid are you feeling today?

1 Like

You keep pointing to Spectre PoCs but to my knowledge we have yet to observe the use of this exploit in the wild… despite knowing about it for six years! There are all kinds of crazy proofs online, the question (to me, anyway) is whether anyone interested in you personally is sophisticated and dedicated enough to pull such a thing off.

Obviously this analysis should not apply to public-facing or commercial services. But for homelab stuff should we really be sweating meltdown or spectre?

by pap-firewall do you mean opnsense/pfsense? Also, Im less worried about the driver vulnerability; but more worried about the direct access to the pci bus. I`ve read online that this allows direct access to system memory; is this a bad take?

PAP as in Package Filter - Application Control - Package Filter, makes it a lot less likely to have tampered packets fool the app control. It is a defense in depth to the point of being overkill for most scenarios. Does not matter what three firewalls you set up for this, just have to be at least two different vendors (and no two same vendors in a row).

Direct control of any system-bus is danger-zone. Software from questionable sources should not be run on a whim, especially not device drivers.

The talk I posted as an example is a practical use, to break a “secure” enclave…

I can not decide that for anyone except myself.

My storage-boxes have no way to talk to the internet because I do not trust myself to not fumble a firewall rule (one can not audit oneself), which makes updating or installing things a pain, but I can live with that.

It is not really a practical example in my mind as, if I understand it, it requires at least unprivileged access to your box!

Air gapping is no real defense if you want to be really paranoid.

I mean fundamentally I agree with you. We should all probably be monitoring our pets a little closer for fleas. At the same time I suppose I live a little more dangerously than you…!

If your attack scenario is “cyber-war against the CIA and NSA”, then you should not be asking security questions on a forum lol

1 Like

Isn’t that the entire point of running a vm is so that I can? does this mean gpu passthrough vms only offer convenience, but not security?

In theory, nothing is perfectly secure. In reality…

1 Like

Is it even secure at all though?

DMA over PCIE → SLOTSCEAMER

you may be interested in AMD-Vi | Intel VT-d: Using IOMMU for DMA Protection in UEFI Firmware
https://www.intel.com/content/dam/develop/external/us/en/documents/intel-whitepaper-using-iommu-for-dma-protection-in-uefi-820238.pdf


IOMMU is one of the mechanisms Qubes uses to sandbox and isolate process memory:

What is a DMA attack?

Direct Memory Access (DMA) is mechanism for PCI devices to access system memory (read/write). Without VT-d/AMD-Vi/AMD IOMMU, any PCI device can access all the memory, regardless of the VM to which it is assigned (or if it is left in dom0). Most PCI devices allow the driver to request an arbitrary DMA operation (like “put received network packets at this address in memory”, or “get this memory area and send it to the network”). So, without VT-d/AMD-Vi/AMD IOMMU, it gives unlimited access to the whole system. Now, it is only a matter of knowing where to read/write to take over the system, instead of just crashing. But since you can read the whole memory, it isn’t that hard.

1 Like

Solution: don’t use your vm with gpu passthrough to run sketchy shit. Filter its access to the web, don’t use it for general browsing.

To escape the VM via hardware passthrough and get to your host or otherwise VM escape, the VM itself needs to be exposed to malicious code.

Avoid that. You aren’t limited to just a single windows VM on your host!

Use it only for the specific windows accelerated 3d workloads you can’t run on the host. need a windows vm for other non gaming/3d stuff? Make another vm and don’t do hardware passthrough on that one.

Even better, learn how to use sysprep and cloning to spin up disposable windows VMs for various things as and when required.

Just because you spent the time to set up GPU passthrough/VFIO for a Windows VM, doesn’t mean you have to run all you windows workloads though it.

3 Likes

I am still having trouble wrapping my head around a case where this is a real concern. If you are trying to run a cloud gaming service I get it. If you are talking about a personal hypervisor so you don’t have to pfaff about with dual booting, then it’s an abundance of paranoia.

Who is the attacker we are afraid of here?

Advertising companies, “social” media providers, privacy-ignoring electronics maker (like LG with their default “send to mothership”)
The attack scenario is turning into “Everyone wants all the data”, and the vulnerabilities in current hardware make it somewhat trivial to get to it.

None of those groups should have access to a gpu inside a vm on your local network?

Exploiting some GPU-specific vulnerability from a VM can be an issue, if that VM is used to study malware behaviour or if the VM is used to isolate spying software from sensitive data on the host.

The issue to be aware off is that a VM (of any kind, including Java-virtual-machine and browser sandboxing) can be broken out off.

To keep Micro$oft from hooking into chrome or a single misclick from stealing session-tokens as happened here, a simple virtual OS install will suffice.


If any possible mitigation strategy is worth the effort depends on the individual threat model.