Another blog article: https://incoherency.co.uk/blog/stories/librem5-first-impressions.html
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
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.
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.
It’s a jungle out there, @amosbatto.
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:
Let us start with a general fact that USB 3.0 supports so called Direct Memory Access (DMA) which helps to minimizes CPU usage.
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).
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)