Without getting bogged down in the actual dispute here (between you, Amos and ‘Daniel’) … the above-quoted text skirts on the edge of falsehood.
You will see in this forum that various people are having problems with the WiFi/BT card in the Librem 5 and they are able to download updated firmware and create the firmware directory and drop the downloaded firmware into the firmware directory and magically the card will use the updated firmware.
I appreciate your reply.
[strcat] Librem 5 has a bunch of components where they are not shipping updates.
[you] … the above-quoted text skirts on the edge of falsehood …
I understand your point, but disagree. When a difference in word choice means a difference in whether the device is RYF compliant or not, it is not just a “doesn’t matter” difference. And in that context, “technically true” is not really “the edge of falsehood”.
I was making no comment at all about RYF compliance. It was only a comment on the text
“Purism isn’t shipping updates to the proprietary firmware”. In order to be true or false, you need to define precisely what you mean by “shipping updates”.
If you mean "apt upgrade will not update the firmware" then that is true.
If you mean “other user shell commands will not update the firmware” then that is false.
In either case, the files will all come from a web site controlled by Purism. In either case, it is initiated by the user.
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)
In addition, Purism provides instructions and blobs to update the firmware for the RS9116 WiFi/BT and the USB controller, @Kyle_Rankin stated that Purism intends to provide firmware updates, and @dos explained in detail to user u/GrapheneOS on Reddit how firmware updates can be done for the major components in the Librem 5.
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?
Please stop this pattern of behavior.
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.
Hallelujah. Now we are talking on the right channel, meaning discussing the actual subject and Schulz Von Thun can finally lay to rest.
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.
I’m not an expert either, but I believe that USB 3.0 has DMA for standard data transfer. Citations:
https://www.ximea.com/support/wiki/usb3/Bandwidth_optimization
Let us start with a general fact that USB 3.0 supports so called Direct Memory Access (DMA) which helps to minimizes CPU usage.
https://www.edn.com/usb-3-0-everything-you-need-to-know/
For the same image size transfer, there is a low CPU load with FireWire and USB 3.0, because both interfaces work with DMA (Direct Memory Access).
Also: https://www.researchgate.net/figure/DMA-configuration-in-USB-30-architecture_fig13_311678516
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.
Purism intends to have an avenue in case if we can liberate firmware bits to make updates for it available.
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.
Let me change the question.
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.
I’m not an expert, but this contradicts what you say. It reinforces that USB 3.0 is vulnerable unless the host deprecates to USB 2.0. The problem as I see it is that all higher-than-USB2-speed data transfers use DMA. https://security.stackexchange.com/questions/118854/attacks-via-physical-access-to-usb-dma
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.
While USB 3.0 leverages direct memory access (DMA), every data transaction still has to go through the USB 3.0 host controller, which adds some amount of overhead and latency.
(https://www.automate.org/industry-insights/usb-4-0-will-enhance-usb3-vision-standard-to-push-pci-express-to-the-device-edge)
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.
