I’m not aware of any USB 3.0-based DMA attacks (but I’ll be glad to learn about them if they exist). Looking at your links it seems like it’s the xHCI-SoC interface, which means that the xHCI host could potentially perform a DMA attack, but that doesn’t extend to USB 3.0 peripherals the way it does with Firewire or Thunderbolt.
USB 3.0 can be especially problematic. I’m not talking about 3.1 allowing DMA when the host says OK, but running outside the kernel. USB 3.0 runs as a binary blob in the BIOS, much like the Intel Management Engine. See this and this. It has a very large attack surface, adding to the already large surface area of the USB host controller hardware. You can disable it in many BIOSes, usually under a name like “xHCI controller”. Doing this will effectively turn all 3.0 ports into 2.0 ports which decreases their speed, but it improves security a good bit. In terms of paranoid security, 1.0 is not good, 2.0 is bad, and 3.0 is a nightmare.
Doesn’t seem so. It mentions USB 3.1 allowing DMA “when the host says OK”, and then talks about how Intel’s implementation of xHCI uses “a binary blob in the BIOS”. i.MX 8M Quad uses Synopsys DWC3 as its USB3 core.
I’m still unable to find a single reference to a DMA attack over USB 3.0, while I can find plenty of them regarding DMA attacks over USB-C by using Thunderbolt 3 or USB 4. Every mention about USB 3.0 DMA (that isn’t actually about 3.1) seems to be about xHCI, not about the peripherals.
Madaidan made a similar argument about unsafe USB drivers, and as I stated in my critique of Madaidan’s article, the only evidence that he provided for his assertion was a link to another article that criticized Linux because it was written in a memory unsafe language. I pointed out that Android also uses USB drivers written in the same memory unsafe language. If Madaidan or Micay had pointed to security holes found in the USB drivers, then I would have taken this critique more seriously, but it strikes me as a theoretical argument that can be applied to any part of an OS.
“strcat” goes on to argue that an IOMMU is better because it isolates the components in the SoC, such as the GPU, to which I responded:
I stated that “the Librem 5 doesn’t need an IOMMU” to isolate the WiFi/BT, cellular modem, GNSS and USB controller, but in case you are worried, the i.MX 8M Quad SoC in the Librem 5 does have a Resource Domain Controller (RDC), Arm TrustZone and On-chip RAM (OCRAM) secure region protection, which does isolate the CPU, GPU and VPU. See section “3.2.2.4 Resource Domain Control and Security Considerations” in the i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual.
There’s been a lot of interesting information here about USB, security, etc. Instead of having it get lost among the many posts on the forum, could we get this in the community wiki?
Also how long is it expected to take to get a gitlab/wiki account approved? I’d put a neutral point of view summary of this in the wiki if my account was approved and someone could give me a few tips about the way to structure things in the wiki.
Also we need the sort of application isolation that Android provides. I’m starting to look into this (currently at the stage of reading documentation and reading source of other things that have similar features). I think it would be good to have some pages in the community wiki to collate information about such things, help us plan how to do it, and hopefully find more interested people.
Should we create a new thread? This stopped being about First Impressions a long time ago.
Which he pointed out is just assertions and marketing fluff. And I agree. Tell me why it wouldn’t be better to have an IOMMU. Tell me why the RDC, and other TradeMark marketing terms(Arm Trust Zone" and references to NXP’s 3.2.2.4 make an IOMMU irrelevant. I wager that you can’t and/or don’t know. strcat was calling you out for not backing up your assertions and, instead, having a string of marketing fluff that he judged as being an off-topic distraction in a wall of text.
I think the problem is that most of it is theoretical - and would be unhelpful in the Librem 5 Wiki. In addition, some of it seems to be unresolved.
The bottom line for any claimed exploit is: Proof of Concept.
Of course if you want to create a new Wiki page devoted to theoretical discussion of USB security, that might be interesting regardless. I’m just not sure that I would trust anyone writing here to be sufficiently au fait with the absolutely nitty gritty of the bloatware USB specification. So I would be looking for citations to said specification.
I have focused my many edits in the Librem 5 Community Wiki on the basic question: How does this help someone else?
I think it’s a manual process - and may sometimes get lost in a flurry of other requests - so it may be a good idea to follow up.