I had a debate on r/Purism about whether RYF certification of the Librem 5 will allow updates of the proprietary firmware in components. My reading of the RYF criteria is that updates of proprietary firmware are allowed, but others disagreed.
To resolve this question, I sent the following email to licensing@fsf.org on June 6 to ask whether the RYF certification allows proprietary firmware to be updated or not:
Dear FSF,
We have been having an ongoing debate on r/Purism about whether the Respects Your Freedom certification allows firmware to be updated or not.
This started because madaidan, a developer of Whonix, criticized the security of the Librem 5, because he believes that the RYF certification does not allow the firmware to be updated.
Since the text of the RYF criteria can be interpreted in both ways, can you please resolve this debate by letting us know which interpretation is correct.
PS: It would also be helpful to update the RYF criteria page so there is no longer ambiguity on this point.
Sincerely,
Amos Batto
Unfortunately I got no reply from the FSF, so I sent the email again today on June 17.
Since the FSF has not responded, I would like to hear what is Purism’s position on this issue. Does Purism plan to provide proprietary firmware updates from the manufacturers of components in the Librem 5, such as the BroadMobi BM818, Redpine Signals RS9116 and STMicroelectronics Teseo-LIV3F? Will there be a way to update the proprietary DDR timing code stored in the SPI Flash Winbond W25Q16JV-DTR?
I can’t answer your original question but bear in mind that if the cellular modem supports FOTA then updates could happen to the firmware of the cellular modem whether you want it, whether PureOS wants it, whether Purism wants it.
Nowhere on the FSF website is it written that this prohibits firmware updates.
I think there is confusion with the fact that proprietary software should not be integrated or facilitated by certified free distribution, for example.
But you can install what you want on certified device, it’s the very principle of freedom…
By the way, Android smartphones are much less secure because firmware and software are rarely or never updated and everything is integrated into the SoC unlike the L5 where the peripherals are connected via USB or other busses.
This has been my impression also. For example, if you have a nice “update firmware” button that automatically fetches and installs the latest proprietary firmware, then I think that could disqualify the device from getting the RYF certifiication. However, that does not mean it must necessarily be impossible to update firmware, just that the device does not specifically facilitate it.
I agree it would be good if the FSF would clarify this, how exactly they draw the line. For example, suppose there is a hardware component that has a separate physical port intended for firmware updates. Then, if it’s known/believed that only proprietary firmware exists, does that mean the physical port must be hidden or even destroyed on a device in order to get the certification? What if a FLOSS firmware version appears later, would it be okay to leave the updating possibility to allow for that?
This topic seems to be similar to the question of using updated bluetooth firmware in place of the one provided on rom. There’s been an answer by @nicole.faerber on this thread:
But we didn’t follow up the topic to the point that Purism and FSF came to a position.
The actual text of the RYF certification requirements says that it can’t be intended by the device manufacturer for the final owner to update the firmware. An important note is that the RYF certification predates the modern all-in-one SOCs for phones, and was aimed more at laptops than at phones. The primary “black box” device with firmware stored in a second place and not using the CPU would be the hard drives, or the fairly sophisticated firmware in a blu-ray drive. The expectation, as set forth in the RYF text, is that the whole, integrated, device (the laptop, phone, et cetera) will work to specification at time of release without the user having to directly deal with closed source firmware.
The rational is that the particular bit pattern which constitutes the firmware is relatively fixed, and so is essentially hardware. Of course, just like the company need not glue the case shut to prevent the end user from using a shunt-mod to overclock the GPU, they similarly don’t have to clip off the JTAG pins to prevent the user from rearranging those bits however they like. They just must not expect the user to do so (or have software on the machine to do it for the user automatically) in order to have a correctly functioning machine.
Of course, that’s just what the RYF text says, I can’t speak to what the current leadership of the FSF or Purism will claim, which is what’s going to actually matter here.
Oh, as for the “at time of release”, just like if it were discovered the wrong resistor was used in a current sensing circuit, a flaw discovered in the firmware wouldn’t invalidate the RYF certification. The RYF certification would, however, require Purism to treat it as a hardware bug, which means offering RMAs to anyone who wants to ship it back for Purism to do the firmware update, same as if there were some other hardware defect. Just like hardware defects though, they could offer the option of doing the “repair” yourself, without voiding your warranty.
Last time this was discussed I never got around to posting a response on here but I wanted to say then that I believe it should be the choice of the user whether to update proprietary firmware or not. That is a user freedom, and freedom is what brought me here and to Linux in general. Restricting the end user from that choice is the opposite of freedom. I’m curious, is everyone here in agreement that it should be updatable by the user?
But as @kieran pointed out the modem could potentially update itself, so it’s not like fixed offline hardware.
Right, the user shouldn’t have to update firmware but I would hope and believe it should be that the device does facilitate it. Updates obviously couldn’t be included in the RYF operating system but it shouldn’t prevent it and shouldn’t require specialised hardware to do so. That’s how I think it should be.
Exactly, these are excellent reasons it should provide that possibility.
The question is what did the FSF mean when it wrote: “software installation is not intended after the user obtains the product”?
As I said in my reddit post, “not intended” is different than “not allowed”, and it is unclear what the FSF meant by “not intended”:
I don’t think the FSF is prohibiting that the firmware ever be upgraded in the Broadmobi BM818 or Redpine Signals RS9116 on the Librem 5. The FSF explicitly says that its exception covers the “firmware built into an I/O device.” The FSF knows that firmware for I/O devices can be upgraded, but most users don’t upgrade them. The intention of the manufacturer is that the firmware doesn’t need to be upgraded after sale in order for the device to function, but something unexpected like a security hole or a bug may be discovered in the future that wasn’t intended.
I suspect that the FSF put this language about “software installation is not intended” to prevent manufacturers from trying to exploit the exception for secondary embedded processors. For example, a manufacturer could add a secondary processor that runs Android with proprietary apps and then try to get RYF certification for the device. The FSF only wants its exception to be used for low-level stuff like firmware, but there is no good way to draw a clear line between an Android app and low-level code, so FSF says that this is code that isn’t intended to be installed after sale.
Maybe I’m wrong in my interpretation of the text, but it seems to me that the FSF was being purposely ambiguous by using the words “not intended”. It didn’t want to say “not allowed” and it didn’t want to say that it endorses proprietary firmware updates, so it used vague language in the middle that gives it some wiggle room. It doesn’t want users to be installing proprietary software on a RYF device, but it has to recognize that proprietary firmware updates are necessary in the real world.
If there were any modern WiFi/Bluetooth, cellular modems and GNSS devices with free/open source firmware, then the FSF can draw a hard line between software and hardware, but there aren’t any and there probably never will be any due to the patent situation, which makes every manufacturer try to hide its implementation details to avoid patent lawsuits. If the FSF tries to draw a hard line, all it does is punish companies that are trying to live up to its ideals, and the few companies that care about free software will throw up their hands and conclude that there is no point in working with the FSF.
One of the reasons why I preordered the Librem 5, and not the PinePhone, is precisely because I believe in free software and I want to support a company that collaborates with the FSF to spread its ideals. It makes me irate that people are now using the RYF certification as a reason to publicly criticize the security of the Librem 5.
The other thing that annoys me is that if the FSF clarifies that proprietary firmware updates are allowed on RYF devices, the critics will say that the FSF isn’t holding to its ideals and the organization is going downhill now that Richard Stallman is gone. In the real world, not allowing proprietary firmware updates does nothing to advance software freedom or user rights. If RYF doesn’t allow proprietary firmware updates, it doesn’t make it any more likely that we will get free firmware for wireless devices in the future, but it does mean that makers of devices with wireless communications will never try to get RYF certification in the future, and companies working with the FSF for RYF certification has real value in promoting software freedom in the world.
At least in theory, if proprietary firmware updates were forbidden, that would create a stronger incentive for someone to create a wireless device with FLOSS firmware. I guess your point is that this will not happen in practice, but why exactly is that?
Because, at present at least, in the US and allied countries, you legally cannot create an open source firmware for cellular devices. At least, not without facing the high probability of having to fend off multiple lawsuits from patent trolls.
It would create a marginally stronger incentive for an open implementation, but at significantly increased cost and risk. That’s not a winning situation. Instead, it would likely lead to the FSF certification being meaningless, as the list of devices with it would remain 0. Note that, to the best of my knowledge, there isn’t a single device on their certified list which doesn’t use closed source firmware. Again, disk controllers count, and are pretty much all closed.
It would be a very difficult task to create free/open firmware for a wireless device without the manufacturer providing information how the device works. You can’t figure it out by watching the input and output, and they don’t provide memory dumps so you can’t watch what changes when you send in a particular command. Most of the wireless chips don’t even publish their data sheets, application notes or reference designs and you can only get that info if you sign an NDA.
If a manufacturer decided to provide details about how its wireless device works, it would open itself up to all sorts of patent lawsuits. Its competitors might suspect that their patents are being violated, but they often can’t prove it without knowing the implementation details, so manufacturers hide all the information that they can.
The only hope that we have is if we get info from rouge employees at chip companies, but who is going to destroy their lives just so some geeks can have free/open firmware? At any rate, any info we might get wouldn’t be useful with the next generation of chips. If Purism tried to sell a product with that free/open firmware included, it would probably also get sued out of existence for patent violations. Even if the chip company was OK with it, any company with one of the thousands of wireless patents could destroy Purism.
Finally, the FEC probably wouldn’t allow the device to be sold, for fear that someone might rewrite the firmware to violate FEC rules for frequency use.
Sadly, there is no way to pass laws to abolish patents, because the patent holders have way too much lobbying power. The only solution is to wait for the apocalypse when the insane legal system collapses or stage a revolution which abolishes all patent law.
RYF is clear that any software that can be updated using the CPU must be free software. Our (Purism’s) interpretation is that it does not force a requirement that firmware cannot be upgraded out-of-band from the CPU, or external to regular software updates.
We designed the Librem 5 based on RYF requirements, believe we comply fully, and are in the process of getting certification. In addition to that requirement we also believe a user should have freedom over their hardware similar to Freedom 0 (that one should be able to use free software for any purpose). As applied to hardware this means that 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.
This is significant because burning fuses on firmware is sometimes used as a security control, so attackers can’t overwrite it with malicious software. Yet it also is often used as a control to prevent legitimate users from “rooting” their devices and installing third-party firmware or software of their choice. In fact I’d argue many companies are using the security control more as marketing cover when the real reason behind burnt fuses is to give the vendor tighter control over the hardware at the expense of user freedom.
Beyond that, preventing out-of-band reflashing of firmware would also prevent us from offering a free software alternative to the proprietary firmware to be reflashed later on if we were able to develop it in the future. This isn’t far-fetched either, as we have done exactly this with coreboot and PureBoot firmware on our laptops.
Thanks for replying @Kyle_Rankin. Good to hear that Purism won’t prevent updating the firmware in the hardware. Still, that leaves large questions for me about how feasible it is for normal users to upgrade the firmware.
I see that Chestnut has BOOT_MODE1 and BOOT_MODE2 pins on the back and “Serial Downloader support (loading u-boot via USB)”.
Will there be some special boot mode where new firmware can be flashed (such as from a MicroSD card or over a USB cable connected to a PC)? (That would seem to be allowed by RYF under the “embedded secondary processor” exception, as long as the special boot mode was executing on the Cortex-M4 core in the i.MX 8M Quad or the separate Cortex-M4 used by the smartcard reader or in the USB PD chip.)
Or are you saying that we will have to take out the M.2 cards and put them in a PC to flash the firmware for the BM818 and RS9116 and use special external tools that don’t come with the Librem 5 in order to update the firmware for the other components on the PCB, such as the GNSS and the SPI Flash memory chip holding the proprietary DDR timing code?
Then how is the “Vikings D8 Workstation” RYF certified? It ships with a Crucial hard drive or Crucial SSD, the firmware for which are not open source, and can be updated via a special dd module from Grub. Such an update has been necessary in the past to fix Crucial drives soft locking due to a smart counter error after 5000 hours of on time. Obviously, I don’t expect you to have personal knowledge of the certification process for another vendor’s item, but if your analysis is correct, it should not be RYF certified.
Methods to flash the firmware on the Librem 5 are outside of my area of expertise. I would expect that we would document the process in our Librem 5 developer docs at some point, when it’s relevant (such as when there’s an update to apply).
Thanks for taking the time to respond. I’m very glad to hear it’s not being prevented. That was my biggest concern.
It would be nice if it were that easy. I hope that will be the case for Evergreen but if not maybe they’ll have something like that for Fir. There are probably more important things to work on for Evergreen.
If it is being updated by GRUB, then proprietary code is being executed on the main processor by the main operating system, so the secondary embedded processor exception in the RYF criteria doesn’t apply. This was exactly why I asked the FSF what it means by “software installation is not intended after sale” and why it wrote “not intended” instead of “not allowed”. It seems to me that the FSF must have known that there must be exception like this for security holes and bugs in the hardware:
The intention of the manufacturer is that the firmware doesn’t need to be upgraded after sale in order for the device to function, but something unexpected like a security hole or a bug may be discovered in the future that wasn’t intended.
My point is that the FSF should be upfront about this unacknowledged exception in its RYF criteria, so people don’t think that they have to live with hardware which might be discovered to be buggy or insecure in the future.
If I’m wrong in thinking that the FSF has an unacknowledged exception for problems like the Crucial SSD, then the Librem 5 could design a special boot mode that only executes on a “secondary embedded processors” (the Cortex-M4 core in the i.MX 8M Quad, the separate Cortex-M4 processor for the smartcard reader, or maybe the USB PD chip) for updating the firmware. Otherwise, the only solution is to put the Librem 5’s M.2 cards in your PC and upgrade them there, and do some strange workarounds like soldering wires on the Librem 5’s PCB and use an external device to flash the chips.
If the Librem 5 needs to have a special boot mode running on a Cortex-M4 core, I want Purism to have thought about it before releasing Evergreen, so it can be implemented later in the software and there is nothing in the hardware that prevents it from being implemented.
The more that I think about the RYF rules, the more I think that RYF is simply a poor strategy for promoting software freedom. You can’t build a modern ICT device without WiFi/Bluetooth, SSD controllers, and a dozen other things that require proprietary firmware updates.
At this point, we should acknowledge that the community has only managed to create free firmware for 2 families of WiFi/Bluetooth devices (Prism54 and some Broadcom 43xx) and the firmware is experimental (i.e., doesn’t work well) and it only runs on ancient devices that only support 802.11b/g. The idea that the community is going to reverse engineer the firmware for a modern 802.11n/ac/ad/ax device is ludicrous.
Every single free driver for a recent WiFi/Bluetooth device was either written by the manufacturer (Intel, Marvell, Redpine Signals, Qualcomm/Atheros, Realtek, Broadcom, Texas Instruments) or was based on code and/or documentation from the manufacturer (MediaTek/Ralink, Marvell), and not reversed engineered by the community. What happened was that WiFi/Bluetooth manufacturers decided that they wanted to be able to sell to the Android market and/or server markets, and the Linux kernel doesn’t deal well with proprietary drivers, because upgrades in the kernel can break the driver, and there were also security concerns with using binary blobs. The WiFi/Bluetooth manufacturers got feedback from device makers that they wanted them to release free drivers for the Linux kernel and market pressure made it happen.
The question is how to get WiFi/Bluetooth manufacturers to release free firmware for their devices (or documentation so the community can create firmware). The only viable strategy is to gather together a bunch of device makers who can pressure/incentivize the WiFi/Bluetooth manufacturers. It is the same situation with SSD controllers, USB controllers, cellular modem/GNSS, etc. The patent situation makes if very difficult, because no manufacturer wants to give competitors their implementation details for fear of patent lawsuits, but if we are ever going to pressure the component manufacturers to release free drivers and free firmware, we need to have a block of device makers demanding it.
As it stands now, the FSF has no ability to organize the device makers to call for free firmware, because most RYF device sellers just take equipment made by other companies and install free software, so they have almost no ability to influence the original component manufacturers. If Vikings, Ethnotechnical, MiniFree, Libiquity, Zerocat and NitroKey call up WiFi/Bluetooth manufacturers and say, “we would like free firmware for a WiFi/Bluetooth chip”, they will get laughed out of the room. If Purism and Raptor Computing Systems call up, they might get a polite email saying its not possible, because they manufacture new hardware, so they are talking to component suppliers.
Imagine, however, if we have a block of 40 Linux hardware manufacturers all asking for free firmware. Then, we have some real leverage in the electronic component industry. For that reason, I think that the FSF should create something like a “best practices” certification, which is based on classifying the manufacturers of each type of electronics component.
For example, in CPUs:
“Heroes” category (provide free drivers and free firmware, or firmware is not needed):
IBM Power9
“Providers” category (provide free drivers, that the community can integrate into Linux):
Qualcomm Snapdragon, Broadcom BCM2711, Amlogic S912
“Sharers” category (share information about hardware so community can create free drivers):
Samsung Exynos
“Community” category (the community has reverse engineered free drivers):
Allwinner A64
“Garbage” category (there are no free drivers):
Apple A-series
Then, FSF can certify devices as “best practices” if they select the best available components. For example, for mobile devices, there is no CPU in the “heroes” category, but there are several in the “contributors” category, so the device has one of those. Then do the same with other component categories (WiFi, cellular modem, GNSS, SSD controller, etc.).
Then, component manufacturers will start looking at the list and plan how they can be moved from “contributors” to “heroes”, or from “sharers” to “providers”, because they know that it will help when trying to sell components to makers of “best practices” devices.
That was essentially my take on how the RYF certification should work. Instead of a pass/fail, it should probably be a grade or rating, and require best effort on the part of the device manufacturer. Make the review process open, on the FSF mailing list, with a public comment period.
As a side note, there actually is an open firmware SSD out there, not sure what pricing, availability, or reliability is, but it is worth noting.
I think there is a misunderstanding on the part of Purism (and others) about what it means to “execute code” on the main CPU. This is something that comes up regularly with the AMD GPU firmware files, so I suppose it’s not a surprise. Let’s consider some concrete examples and see what we can figure out.
First example is the NVidia GPU firmware. There are several pieces of firmware, some of which is provided in the linux-firmware package, and some of which is provided only by the closed source driver. Without any firmware provided at runtime, the GPU runs in ultra low power mode, basically VESA only. The firmware included in the linux-firmware package can be uploaded to the card by the (open source) nouveau driver, and unlocks slightly better performance. This is essentially a file copy, no closed source code runs on the CPU. To get full performance out of the card, the nvidia kernel driver must be loaded, which then uses a cryptographic handshake with the GPU and uploads the remaining, signed, firmware files. This kernel driver runs on the CPU, and stays running after uploading the firmware. Obviously, this is a problem. It would be a problem even if the firmware itself were open, as the card will only accept the firmware if it’s signed, and only from the closed source driver, running in kernel space. Again, to be clear, the firmware updater is closed source, runs on the cpu, in kernel space, every boot.
The next example is the recent AMD GPUs. This time the firmware files are all provided by the linux-firmware package. They are all closed source, but one of them is well documented and can be modified by the end user (it’s just a table of power, temperature, and thermal limits for the card). The firmware is sent to the card by the open source AMDGPU kernel driver. Once again, sending these files amounts essentially to a file copy, with no closed source code running on the CPU. This doesn’t qualify for the RYF certification only because the firmware must be sent to the GPU on every boot.
In the next case, let’s consider the RAM timing training for the Librem 5. This is a blob of executable code provided by some device manufacturer (not sure if it’s the memory, chipset, or CPU manufacturer, but it doesn’t really matter). It must run on some CPU core, every boot. Just like the NVidia driver, it is not firmware, although it may contain firmware. Purism makes it effectively firmware by isolating it to a CPU core that is then not used for anything else.
The next case is the firmware update for a desktop motherboard. This is done by the existing BIOS, followed by a reboot. The updater itself is closed source, and runs on the main CPU, but only runs once, and then resets the computer. The problem here is that the BIOS itself is closed source, not that the updater is closed source.
The last case is the Crucial SSD firmware update. Unlike the previous cases, this firmware update runs in userspace, using standard POSIX tools. It literally is just a file copy (dd if=newfirmware.img of=/dev/sdx) . It also only runs once, and is not normally needed.
I’m not certain I’ve made the situation clear, but the bottom line is that some firmware updates require running closed source code on the main CPU, and some only require copying a file through a particular protocol, with no closed source code executing on the CPU.
I’m guessing that this would be acceptable under RYF, since the only code executing on the main CPU is dd, which is free software. The proprietary firmware code isn’t being executed, simply being copied to another device. I think that all your other examples would violate the RYF criteria.
Yes, a grading system would be better than simple pass/fail. It would take a lot of work to compile a list of hardware and rank how much each component promotes freedom, but I bet that FSF could find volunteers to work on it.
In my opinion, the FSF has largely fulfilled its original mission of a free operating system and free software applications. At this point, the critical work moves to free drivers, free firmware, and free hardware. It bothers me that the FSF does so little to engage the electronics industry. If the FSF was scoring devices in terms of their freedom promotion, the device makers might actually pay attention.
For example, the FSF could create a “Freedom Score”, that assigns a score between 0 and 100 to a device, based on how much free software and free hardware it contains. Purism used to have the highest laptop score in the industry. When System76 introduced laptops with Coreboot and free/open EC firmware, it would have closed the gap with Purism (with a reduction for proprietary WiFi firmware, but a gain for its free EC firmware). When MNT Reform ships, it will become the highest scoring laptop in the industry.
Currently reviews just say that the Dell XPS, TUXEDO InfinityBook Pro, Purism Librem 15, System76 Lemur Pro, and MNT Reform are Linux laptops, but imagine the dynamic if they get Freedom Scores of 55, 60, 75, 75 and 90, respectively. Suddenly, it becomes really clear which laptop is better in terms of software and hardware freedom, and I bet the MNT Reform would have more than 220 preorders.
Now imagine the dynamic with Dell engineers asking, “Can we switch the GPU from nVidia to AMD to get our score up to 60?” TUXEDO asks, “Can we finish our Coreboot port to get our score up to 70?” Purism asks, “Can we change our keyboard and fan controller, so they use free EC firmware to get 3 more points and beat System76?” System76 asks, “Can we switch our WiFi from Intel to Redpine Signals to eliminate the proprietary firmware and get another 2 points?” PINE64 asks, “Can we publish our schematics of the PineBook under the GPL to match the score of the MNT Reform?”
Suddenly, the device makers care what the FSF thinks, and they start talking to component makers, asking for free firmware, and they start asking Intel for permission to release their schematics under a free license. It sets a totally different dynamic in the industry.
