Thread on how the Librem 5 is explicitly designed to hide proprietary blobs from the user in order to gain RYF certification (where having those blobs readily accessible would be strictly an improvement in freedom, as it would mean you are free to verify their contents, audit them, and potentially replace them with a free version if you develop one):
https://twitter.com/marcan42/status/1040626210999431168
Make no mistake, Purism has gone quite far down the freedom marketing religion path laid down by the FSF. They no longer care whether you're free or not, they care that you believe you're free.
If you have blobs, stick them in /lib/firmware. Don't go hiding them in separate flash chips that I can't audit or rewrite just so you can slap the FSF's meaningless "the main CPU didn't touch any blobs (except the bootrom but we don't talk about that) so it doesn't have the digital cooties" rubber stamp on your device.
"We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification."
https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
> The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing.
The post you link to is full of wishy-washy fluff, but does not answer the direct question that the user posed in the OP, about the DDR timing code flash being writable.
we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose.
In other words, you can modify the firmware on the Wi-Fi card or modem.
Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.
Edit:
> can’t be modified without the user knowing
> without the user knowing
Did you actually read what you quoted?
That's CSO code for "I have no idea what I'm talking about, but I'm just giving you a canned response about our principles with no technical details and hoping you don't pry further and prove me wrong".
He never explicitly addressed the RAM blob. If he knew it was flashable he would've outright said it to answer the question. But he did not.
> Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system.
Incorrect. The code is loaded in the DDR PHY. It then runs continuously. It is required for normal operation. This is because LPDDR requires continuous runtime re-training at its higher performance modes. What only runs on boot is the (dumb as hell) code they wrote to run on the Cortex-M4 as a workaround, because the FSF's ridiculous requirements forbid you not just from running proprietary code on the main CPU, but from touching proprietary code on the main CPU.
So Purism built code that runs on cpu A to run code they built that runs on cpu B to load a blob from external read-only memory C into cpu D, just so they could claim cpu A never got digital cooties from touching the blob.
Please appreciate the stupidity of this entire ordeal.
cpu B code: https://source.puri.sm/Librem5/Cortex_M4/-/blob/master/ddr_l...
> read only
Means it can't be modified without the user knowing, and it also can't be modified with the user knowing.
Unless the Librem 5 literally has a DIP switch for "enable flashing RAM code", read only means read only, period. It means the write protect pin is tied to protected, or a set-only protect bit in the SPI flash config was flipped.
I have had a conversation with you about this before and I still don't see what the issue here is. Best case, that seems it might be covered under the secondary processor exception, worse case, the FSF would not endorse it. Since you have the ability to reverse engineer this and fix the situation once and for all, why not do it? What is the real problem here? If you are trying to get Purism to pay you for this work, I would suggest contacting them about that privately.
Because Purism selected components for the Librem 5 that will be manufactured for many years, it is more likely to get firmware updates than most smartphones. Because the drivers are all FOSS, they can be updated by the community, and some cases the manufacturer helps maintain the mainline Linux drivers, so timely updates are very likely. For example, NXP promises to sell its i.MX 8M Quad processor until at least Jan. 2028 and it helps maintain the mainline Linux driver. Likewise, Redpine Signals helps maintain the mainline driver for the RS9116 WiFi/BT and likely to keep manufacturing the chip for at least the next 5 years.
In contrast, the SoC used in a typical smartphone is only manufactured for 1-2 years and it typically only gets 2-3 years of support from the manufacturer, so the Librem 5 is more likely proprietary firmware updates than most smartphones.
As for the question of whether it is better to store the proprietary firmware in the /lib/firmware directory or in the component or in Flash chips on the motherboard, there are advantages and disadvantages, so you have to weight what is important. When firmware is stored and loaded from the /lib/firmware directory, it is easier to update and the user will automatically get the latest firmware when upgrading the software on the device. In contrast, the user has do a separate procedure to upgrade the firmware and many users are unlikely to do it, so any potential security holes in the firmware are less likely to be closed with updates. However, a lot of this depends on what Purism does in the future to push firmware updates, so we shouldn't automatically assume that the Librem 5 will be insecure. The benefit of not storing the firmware in /lib/firmware is because it makes the user more conscious of the proprietary blobs on the device, and the user can make a deliberate choice whether to install firmware updates or not, after reading the description of each update. Also, it is harder for the firmware to be hacked by a bad actor when it is stored in the component or a separate Flash chip, because it requires a separate procedure to flash the firmware, so it can be argued that it is more secure. Another benefit is that system updates can be offered without including any proprietary files, so there are no restrictions on how they are distributed and installed.
In terms of promoting software freedom, I don't know of any cellular modems or any GNSS with FOSS firmware. There were only two WiFi/BT model series whose firmware was reverse engineered by the community but they never got past the experimental state and are now hopelessly outdated since they were 802.11b/g devices. There are some ath9k 802.11n models that required no firmware, but they have poor range and are energy inefficient and require proprietary firmware for the Bluetooth.
In other words, there is no realistic way to make a modern computing device without proprietary firmware, and the only hope is to pressure the manufacturers to release code or documentation for its firmware, but the modern patent situation with wireless communications makes that extremely unlikely to happen. However, the FSF's insistence on trying to separate the proprietary firmware and not let it be executed on the main CPU cores does draw public attention to the problem and show the component manufacturers that there is public demand for free firmware. When companies like Purism go through extreme steps to avoid executing DDR timing code on the main CPU cores, by adding a separate SPI Flash chip to the board to hold the blob and not using the Cortex-M4 core for any other purpose but to execute that blob, it sends a message to NXP that its customers really hate that proprietary blob and it should be eliminated. In contrast, a company that stick that blob in the main Linux file system tells NXP that its customers don't care about that blob and there is no pressure for NXP to eliminate it in future chips. The value of buying RYF products like the Librem 5, RaptorCS computers and Lulzbot is that it is creating a public statement that consumers care about not having proprietary blobs, and that the hardware industry should cater to that crowd. What Purism is doing value in promoting a public message and it is based on a long-term strategy to pressure the industry to free its firmware, whereas the people who criticize it have no strategy for ever achieving change. If they have an alternative strategy for how to free the firmware, I would love to hear it.
The more important point is that Purism selected components from hardware companies that are more willing to collaborate with the community and listen to Purism's requests, so there is more possibility of driving change up the supply chain. Purism paid Redpine Signals to modify its firmware so it could meet the RYF criteria and NXP engineers work with the community on the mainline Linux driver for the i.MX 8M, so it is possible to influence these component suppliers.
Let me just start by saying that trust is a very personal feeling. We give trust to others based on criteria that are different. I completely understand that my points listed below are not relevant trust indicators for others.
That being said, I have 2 main mistrust issues with FSF:
1) Leadership
I had various occasions to interact with RSM over the years, in various contexts. I do not have a fond memory of those interactions.
- I remember someone which is very difficult to have a real conversation with. Very childish and binary in his view of the world. Prompt to not listen to arguments, talking louder than others, turning arguments into jokes, etc.
- I worked and know plenty of people who worked with him in various academic labs where he's been invited to give talks or work on subjects. The same complaints emerged all the time: he would grossly hit on female PhD students (just enough to make them uncomfortable), always tried to be hosted by someone and would not even shower there, very rarely participate in the big picture of why he was invited (e.g. He would lock himself in a room for 2 days straight to fix some esoteric emacs bug on an archaic platform, instead of just organizing seminars on free software and participate in discussions), he would act in very narcissistic ways (e.g. After proposing to go to a restaurant, he would then propose - and insist grossly - to pay the bill with his autograph on a printed copy of emacs source code). He would constantly rant on closed source computers and cell phones, but will gladly borrow anyone's phone to make international calls. I stop here because I just have too much random echos of his not-so-pleasant behavior.
Overall most of my personal interactions with RSM, as well as friend's recollections picture him as gross, childish, and narcissistic.
Now RSM himself is not the FSF as a whole, but I have a hard time trusting an organization that is so centered around a single individual which embodies traits that I do not appreciate.
2) The organization members
I did not have direct relation with other FSF members, but I have been contributor to projects where the FSF intervened (or tried to) in the governance.
Most of the time, the FSF members were never contributors to the projects. Yet they were the one trying to dictate the tone and direction, and act like they owned the projects based on their moral high ground.
This has led me to associate FSF members as some kind of a self proclaimed elite class of zealots, exempt of technical knowledge and actual contributions, but still willing to be heard.
This goes directly against my view of governance of open source projects, in which I believe the actual contributors should be ones to set the tone and direction of the project, because they are the one building it.
---
Again, all this is mainly personal feelings, so I don't want to look like I'm trying to influence others into distrusting FSF.
I understand that my interactions with RSM were in a certain context and that he maybe could be a very pleasant person in a different situation. And I also understand that my interactions with other FSF members were limited to the projects I contributed to, and there may be thousands of others where they were helping and constructive.
My main problem with the FSF has been more in terms of poor strategy in terms of how it engages with the software and hardware industry, rather than the philosophical vision.
As for RMS, every interaction I have had with him.has been rough at best. I mean he is definetly right about the issues of software but him as a person can be very difficult at the best of times.
This page has stayed the same: https://ryf.fsf.org/about/criteria
However, I raised a question about how to interpret the RYF criteria with regard to proprietary firmware updates, and I'm hoping the FSF will clarify the RFY criteria in a way that allows proprietary firmware updates for components that don't execute on the main CPU cores. See: https://forums.puri.sm/t/does-respects-your-freedom-certific...
Though that thing about the FSFE office in Germany yesterday... Hopefully it's just a dude and the office he runs rather than the organization as a whole.
If anything, slightly grumpy old school guys (again, alleged) are much better at rejecting corporate influence than the new people whose politics are literally bankrolled by corporations.
I'm not associated with FSF specifically, but as a card-carrying grumpy old-schooler, I object to your vaguely-defamatory characterization of them[0] as "slightly" and "alleged".
Edit: 0: RMS et al, that is, not the business linux people.
(I think hacker culture in general is great, but, to use an analogy, there's a buggy implementation going 'round.)
It's not just an FSFE problem. It's also not intrinsic to hacker culture in any way; it just tags along, causing problems.
What are you referring to?
While having FSF validation is indeed some kind of proof of due diligence, in the end what really matters is the trust that users place in the project itself in following their guidelines.
I do not have a particularly strong trust for the (modern) FSF, so their validation adds nothing, IMHO, in my trust in Purism.