OK, I see. For the record, USB devices can't simply request the host controller to read or write whatever they want, as it was the case with FireWire and Thunderbolt, which is why people say that "USB doesn't have DMA". The controller will only do DMA to/from OS-specified USB buffers.
This SE post says something about DMA in USB 3.1, but I couldn't quickly find any confirmation that something has changed in version 3.1 in that regard. I didn't follow this standard closely, though.
However, 3.x controllers usually run firmware blobs of unknown quality and if a device manages to pwn this firmware then it may turn out to be able to access other memory. I think that's what the poster was worried about.
I don't think it's possible to "disable USB DMA". At least in case of 1.x/2.0 controllers most of the communication between OS and controller happens through RAM data structures and nothing would work without DMA.
> This SE post says something about DMA in USB 3.1, but I couldn't quickly find any confirmation that something has changed in version 3.1 in that regard. I didn't follow this standard closely, though.
Nothing has changed with regard to DMA. What _has_ changed is the introduction of the "Streams" feature which allows the host to establish multiple buffers in advance and have the device choose which of these to write into.
That's useful for asynchronous task delivery, eg on storage (which is AFAIK the only major use case of the feature so far): The host requests 10 transfers, prepares a properly sized buffer for each of them, and the device can fulfill them in whatever order is fastest, directly into the buffer that the OS considers the most useful for the job.
In principle, read()s from USB devices could be mapped directly into the reading process' memory space (in practice that won't happen), without the driver having to copy data around (just some signal when the data arrived and the buffer is valid).
What memory gets written to (and how much of at each address) is still managed by the host controller driver.
> What _has_ changed is the introduction of the "Streams" feature which allows the host to establish multiple buffers in advance and have the device choose which of these to write into.
This feature should be safe in principle, although it does seem to increase HC attack surface a bit ;)
One more thing about 3.1 is that it can share physical ports with Thunderbolt. In such case, an innocent-looking USB gadget may turn out to do interesting things.
> This feature should be safe in principle, although it does seem to increase HC attack surface a bit ;)
The HC attack surface is already significantly increased because XHCI does many things on its own that used to be done in the driver (eg. the whole address assigning handshake).
XHCI is the first USB controller variant that a USB device project I worked on was able to lock up the controller so hard it took a cold reboot of the computer to fix. That was... unexpected.
(and I can't say I'm happy about that type of complexity ending up in places where I can't fix them)
The same is btw. true for SATA, SCSI, SAS: the "DMA modes" (UDMA etc.) mean that the host controller is doing DMA transfers, while SATA drives cannot initiate nor control DMA transfers.
