Someone posted this in a forum.
but I've seen a case where a woman's graphical hardware was locked down by a virus that infected her hard drive and gtx 960, she had to wipe the drive and have the gtx swapped/replaced under warranty.
>>58240417
The drivers yes but the actual hardware?
>>58240507
Yes
>>58240410
PCI(e) devices have full access to the RAM.
GPUs have fully functional CPUs, running the firmware. Theoretically you could conceive a malicious firmware, just like you can infect hard drives, which the NSA has done in the past.
An IOMMU can stop them but most consumer motherboards don't support IOMMU.
AMD is a noble exception.
Their desktop CPUs support IOMMU. (It's actually a motherboard feature but Jewtel is blocking it with their CPUs).
>>58240683
>PCI(e) devices have full access to the RAM.
Not on modern computers, IOMMUs provide isolation.
>An IOMMU can stop them but most consumer motherboards don't support IOMMU.
IOMMUs are part of the chipset, not the motherboard. What consumer grade chipset released the last two years doesn't have an IOMMU?
>>58240699
>>58240683
As for the rest, yes, it's technically possible but not very likely as the firmware is stored on ROM on the card and not easily accessed and overwritten.
It's more likely that someone exploits a bug in the driver that gives raw access to RAM which you can overwrite parts of the OS code in order to do what you want to do.
>>58240699
Most cheaper motherboards don't and all motherboards I've checked which do support it have IOMMU disabled by default. (Asus, Gigabyte, MSI, Asrock, SuperMicro, Tyan, Quanta, Dell, HP)
>>58240738
Disabled by default may be the issue, yeah.
>>58240749
>>58240738
Also, fun fact: Nvidia GPUs doesn't support ATS, meaning that they must either 1:1 mapped in order for PCIe P2P to work. Not really an issue unless you have any PCIe switches downstream of the root complex though.
>>58240507
If it has flashable firmware, and piece of hardware can be hacked.