(untitled)

Is non-free GPU firmware a privacy/security threat? AMD GPUs have FOSS drivers but you have to use proprietary firmware. With CPUs, firmware is clearly a threat, but this is because the code running in that proprietary blob has full access to for example networking. This would not be the case with GPU firmware, correct? So GPU firmware couldn't phone home in the same sense? I guess you could make malicious code in GPU firmware, and for example have it record screen content and save it in VRAM or even system RAM, but if there is no way to send that over the network it doesn't seem like an actual threat vector unless you have people physically accessing your computer and reading the memory? Any thoughts? Of course I'm assuming that the rest of the system is completely FOSS and non-backdoored, excluding any possibility of other computer components accepting for example weird novel network calls from the GPU or something like that.

>>17107 >So GPU firmware couldn't phone home in the same sense? PCIe has full access to host memory (unless you have an iommu). So in theory a malicious PCIe device can take full control just by writing a backdoor into RAM. There is also no real security between PCIe devices either, everything on the bus is equally trusted, so a malicious GPU might be able to drive a PCIe network card directly without help from the host. I haven't done much research into this, just some thoughts to get you started.

>>17108 Are you saying that a GPU could make direct calls to the network device, and that a FOSS network card would accept and handle such novel requests? Wouldn't the firmware need direct kernel access? Which I assume the graphics driver has (in this case FOSS) but the firmware hasn't? As the driver is running in kernel space but the firmware is running on the GPU device itself. And would it make a difference if the network device was on a PCI card, integrated on the motherboard, or on a USB device? I guess the proprietary firmware could ask the FOSS driver to do it but then such a function should be visible in the driver source code. Although I doubt anyone is doing security audits of a graphics driver... it's probably massive too, and it could probably be obfuscated in the code.

All nonfree software is an security threat.

>>17109 > and that a FOSS network card would accept and handle such novel requests? There's nothing novel about it. Any PCIe transactions the host sends any other PCIe device can send too. >Wouldn't the firmware need direct kernel access? PCIe is routed through the MMU so your graphics card can read/write host memory directly without the CPU (and therefor the operating system) even knowing about it. That's why you get a big security warning if you try to pass a PCIe device into a virtual machine without an iommu. The iommu lets your OS restrict which memory locations PCIe can read/write from. But that's still not 100% safe because if network card and graphics card are on the same PCIe bus then they can access each other's memory. So the graphics card could conceivably put packets into the network card's TX queue. >And would it make a difference if the network device was on a PCI card, integrated on the motherboard, or on a USB device? If the PCIe card has full access to host memory (no iommu or misconfigured iommu) then it can probably do anything the host can do really. >I guess the proprietary firmware could ask the FOSS driver to do it but then such a function should be visible in the driver source code. I don't know what you mean here. The way a network card works is it reads packets from a TX queue and sends them on the wire, and takes packets from the wire and writes them to the RX queue. Then the operating system kernel reads/writes the RX/TX queues. If another PCIe device can also read/write the RX/TX queue then no other collusion is required. It's just a hole in the way PCIe works. It's designed for high speed devices. You don't get 4K gaming by interrupting the CPU and asking the operating system permission for every read and write you want to make.

>>17111 So basically no PCI cards are safe to use unless they use FOSS firmware? If what you are saying is true than basically no PCI devices are safe to use, the few that don't require proprietary firmware to be loaded by the OS instead have proprietary firmware on their own ROM Do USB devices have direct access to memory? If so then no mice or keyboards are safe to use, they all use proprietary firmware. >So the graphics card could conceivably put packets into the network card's TX queue How would the graphics card even know what memory sections are designated for the network card? Can all PCI devices read all RAM by default?

>>17110 Of course but the question is always how big is the threat, and threat mitigation. There are basically no peripherals that use FOSS, they all use proprietary software. Most storage devices use proprietary firmware. The question is how big is the threat, do they call home, how can it be mitigated, what threat vectors are you able and willing to mitigate.

>>17112 >So basically no PCI cards are safe to use unless they use FOSS firmware? Depends on your threat model. Security is not a on/off switch. >If what you are saying is true than basically no PCI devices are safe to use Newer CPUs have additional hardware called an iommu which lets the CPU restrict which memory locations a PCIe bus can access. It's called vt-d in intel and something else in amd. https://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html QubesOS has a feature to lock up PCIe devices into isolated VMs if this is something that really worries you. >Do USB devices have direct access to memory? Not until USB 3. What PCIe does is called DMA, Direct Memory Access if you want to read more about it. >How would the graphics card even know what memory sections are designated for the network card? Probably wouldn't. >Can all PCI devices read all RAM by default? Yes without an iommu in the way.

>>17114 Thank you. Is it easy to set up and use IOUMMU? I'm trying to get a system with as few proprietary parts as possible. Apparently nvidia kepler (700 series from 2014) and older don't need firmware to be loaded, and noveau works with them.

>>17114 >>How would the graphics card even know what memory sections are designated for the network card? >Probably wouldn't. Generally what you do in those sorts of situations is just walk the entire memory space and use heuristics to look for a pattern you already know. By default on PCI any device can claim Bus Master, which seems like a terrible idea. Would a machine with IOMMU generally restrict devices by default so they can't just go ahead and do that, or does it let anything directly connected to the host do as it wants?

>>17116 >Would a machine with IOMMU generally restrict devices by default I think it works more like a blacklist where the CPU can say this range of addresses are ok, this range of addresses is not ok etc. So even though hardware might include an iommu it is still down to the operating system to configure it properly.

>>17117 Doesn't IOMMU generally work as a whitelist?

>>17118 >Doesn't IOMMU generally work as a whitelist? OK, yes but also it does nothing by default. So it's a whitelist like a chroot is a whitelist. https://software.intel.com/content/www/us/en/develop/articles/intel-virtualization-technology-for-directed-io-vt-d-enhancing-intel-platforms-for-efficient-virtualization-of-io-devices.html

>>17119 Ah, so that's what Qubes people meant when they said a lot of OSes don't do the required setup...