Another blog article: https://incoherency.co.uk/blog/stories/librem5-first-impressions.html
4 Likes
Is that Daniel Micay from GrapheneOS back under a different name? Interesting that he says that he contacted Purism to ask about porting GrapheneOS to the Librem 5, and then decided that the hardware was too insecure. I have to wonder about that, given how many things he gets wrong in his criticisms of the Librem 5. At any rate, I responded to correct the record: https://news.ycombinator.com/item?id=30769589
5 Likes
Thatâs quite an accusation. You tend to do that to provoke responses to things you want people to correct for you â coerced offloading of work. Youâve done it with me multiple times and I truly dislike it. Itâs exactly why Daniel feels youâre attacking him. I had hoped that the fact that you were banned from the purism subreddit for a month would have clued you into that behavior.
I donât think he has said anything incorrect. If so, please prove it. If youâre referring to his statement here:
[strcat] Librem 5 has a bunch of components where they are not shipping updates.
Various pro-Purism people have interpreted that as him saying that those proprietary firmware updates are not possible. That isnât what he said. What he said is true:
Purism isnât shipping updates to the proprietary firmware. You and I both know they
arenât/wonât since if they did, there is no way the device would be RYF certified.
[Personally, I think the FSF has been clear that if Purism intends for those proprietary
blobs to be updated on the Librem 5, then the Librem 5 would not be certified RYF.]
After having read what he has to say and what you have had to say, I have to agree with Daniel on most everything. There are a few statements he has made that I donât understand, but at this point Iâm assuming that Iâve missed something (instead of assuming he is wrong).
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.
1 Like
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.
6 Likes
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.
1 Like
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.
3 Likes
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.
4 Likes
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.
6 Likes
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.
3 Likes
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)
2 Likes