Not true. Purism updated the RS9116 WiFi/BT firmware from version 1.2.20 to 2.0.0024. Plus, Purism has 4 commits to facilitate firmware updates for the RS9116 (1, 2, 3, 4)
If “strcat” was in talks with Purism to port GrapheneOS to the Librem 5, then he should have known Purism’s position on firmware updates and he should have known that the Librem 5 doesn’t need to use an IOMMU to isolate its components because of the way that the phone is designed.
I guess that I should explain this. I had a debate with Micay about the Librem 5’s security, and he started insulting me and claiming that he was being persecuted. In our second exchange, he accused me of being “involved in direct efforts to organize raids and harassment against GrapheneOS developers”. When I responded with this post, the r/Purism moderator deleted my link to the Techlore video which detailed Micay’s past behavior with other communities and banned me for a month. Those are the only interactions that i have had with Micay.
All of this is off-topic, so I probably shouldn’t have said anything in the first place on this forum.
Not true. Purism updated the RS9116 WiFi/BT firmware from version 1.2.20 to 2.0.0024. Plus, Purism has 4 commits to facilitate firmware updates for the RS9116.
“Facilitating” firmware updates is different than “shipping updates”. You need to understand what “shipping updates” means to an OS developer. Also the discussion was about all firmware including the cellular modem.
By the way, are you saying that Purism intends the firmware in the Librem 5 to be updated after delivery? If so, it violates the “secondary processor exemption” allowing proprietary firmware for RYF devices.
If “strcat” was in talks with Purism to port GrapheneOS to the Librem 5, then he should have known Purism’s position on firmware updates …
It depends on the timing of his discussions. But it’s also why strcat said “shipping updates”.
… he should have known that the Librem 5 doesn’t need to use an IOMMU to isolate its components because of the way that the phone is designed
This is one of those cases where you are so sure of your position that you didn’t read his position. It’s one of those cases where you are so sure of yourself, you accuse someone else of being wrong based only on your misunderstanding. Remember that I’m the one who told you that the USB2 bus (not the USB3 bus) is isolated from DMA (I told you this because I was arguing that the pinephone’s modem and wifi was as isolated as the Librem 5; you continued to obstinately refuse this argument and didn’t ever back off from the opposite position until Luke penned an article). But you didn’t read strcat’s other point in regard to his view about the need for IOMMU: Access to USB2 means that one only has to trigger a bug in the USB driver to have access to the kernel memory. USB2 is electronically isolated from DMA, but USB2 is not isolated from the kernel and a bug in the (monolithic) kernel driver exposes memory.
Did you not read his point or did you not understand his point? You have this habit of not understanding something and then calling them wrong with the apparent attempt to force them to bring it down to your level. That’s not their obligation. I usually oblige, but strcat doesn’t. In fact it’s why he thinks you are trolling/attacking him. And your response to him accusing you of harassing him was to call him paranoid and link to a video to another group that he thinks is attacking him. Did you not learn anything from your ban?
The very same thing applies to the driver for a device behind an IOMMU as well. For such scenario, having IOMMU does not change anything at all. The only difference is that a USB device can pretend to be a different thing than it really is, which would make the kernel use a different driver - significantly increasing the attack surface, as you don’t have to exploit one specific USB driver but can use bugs in different ones as well. However, you can always require manual confirmation to enable a driver for a previously unseen device, which is something we’re already working on (which will also apply to things that you connect via USB-C port).
IOMMU could actually help with limiting the impact of bugs in things like GPU or VPU, as without it they can (mostly) access the memory any way they want. That’s, however, a completely different risk profile than exposing DMA for things like baseband modem or WiFi card, which Librem 5 does not do, and which phones that do usually restrict by using an IOMMU.
The very same thing applies to the driver for a device behind an IOMMU as well. For such scenario, having IOMMU does not change anything at all.
As you will note, strcat also brought that up. He asserts that the attack surface is far smaller. My reading indicates that there is a consensus that having an IOMMU is more secure and that is all strcat was asserting. This is especially true for the future now that USB3 (which allows DMA) is becoming ubiquitous.
But I’m not here to repeat discussions that strcat has already had. I’m here to point out that Amos shouldn’t assume strcat is wrong simply because he doesn’t understand someone else’s points.
I’m not an expect on recent USB versions, so correct me if I’m wrong, but my understanding is that USB3 doesn’t do DMA either; there’s a xHCI feature in USB 3.1 that lets the controller optionally use DMA, but that’s much closer to the GPU/VPU example than anything else (and can be disabled anyway). It’s only USB 4 that does the kind of DMA that can leave you vulnerable to DMA attacks performed by the peripheral.
Also, while discussing potential attack surface, you also have to consider that using IOMMU correctly is a complex and error-prone thing by itself. If you have IOMMU-protected DMA with exploitable IOMMU, you end up with unprotected DMA.
It’s my understanding that full duplex data transfers at SuperSpeed in USB3.0 require DMA. (Edit: It’s also my understanding that it’s not like USB3.1 xHCI where the host can
negotiate on/off. Other than the host deprecating to USB 2.0, there is no way to avoid
DMA attacks with USB 3.0 ).
This further response is also an edit:
[you] Also, while discussing potential attack surface, you also have to consider that using IOMMU correctly is a complex and error-prone thing by itself. If you have IOMMU-protected DMA with exploitable IOMMU, you end up with unprotected DMA.
I believe the consensus is that having an IOMMU is far more secure. That was certainly strcat’s assertion.
Also reading all the links in this thread made me re enable my self ban on reading reddit, and news.ycombinator.com for the next two months, for health reasons.
Does Purism intend the firmware in the Librem 5 to be updated with proprietary firmware after delivery? If so, it violates the “secondary processor exemption” allowing proprietary firmware for RYF devices.
Officially, FSF prohibits such update for the certified devices. But it’s quite unfair and there is an opposition to that, which I hope can win sooner rather than later.
Which is why in the linked thread I suggested to certify the phone without the WiFi module and modem.
We don’t intend to distribute and install any proprietary updates as a normal part of device operation in PureOS (but alternative operating systems are free to use a different policy). We also don’t intend to artificially prevent the user from installing them themselves should they wish to do it for any reason. We do provide firmware blobs for users to download whenever possible and intend to continue doing so. A big holdout for now is the modem firmware, as licensing of the update tools we got from the manufacturer is not clear (at least to me right now), but we’re actively looking into replacing them with FLOSS tools anyway.
The ultimate intention is to liberate all firmwares, but it goes without saying that we’re not there yet.
That’s defined purely by software configuration. You can make it bigger, you can make it smaller (even compared to IOMMU-based configs). We currently have it bigger (because of ability to load arbitrary USB driver), but as noted earlier, that’s temporary.
“Far more secure” than what? Generally having IOMMU is better than not having one, I think it’s obvious, but not having to rely on IOMMU is even better. For some tasks, like with most integrated modems (but also other IPs like GPU), you need to rely on IOMMU to ensure protection from misbehaving component. For others, like USB modem, you don’t, as it’s entirely irrelevant for that use case.
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.
After looking at it closer, it appears that the optional USB 3.1 feature I mentioned earlier is the one that actually could allow peripherals to perform such attacks. We don’t support that at all though.
(edit: also, I want to stress out that I don’t have any formal security background and my role in Purism is not about security; I check and discuss this stuff purely on my own curiosity)
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.
