Today most of the wireless manufacturers (Intel, Broadcom, TI, Marvell, Realtek, Silicon Labs) now release FOSS drivers for Linux, but some of the older WiFi/BT cards have community developed drivers. MediaTek/Ralink and Infineon don’t collaborate well with the community, but most of the manufacturers do (I think the arrival of Android changed this).
For a list of the FOSS drivers, see:
No WiFi/BT manufacturer releases their firmware as FOSS, and it is unlikely to ever happen because releasing the firmware would make it easier for others to discover how they implemented their WiFi/BT, which would open them up to more patent lawsuits. Wireless communications have thousands of patents and many of them overlap, so the manufacturers are very fearful of getting sued for patent violations.
The big difference today is whether the WiFi/BT manufacturer works with the community to get their FOSS drivers included in the mainline Linux kernel, and whether they try to get their proprietary firmware to be included in mainline’s linux-firmware project. If the manufacturer doesn’t work to get their FOSS drivers included in mainline Linux, then volunteers from the community have to do it. Another question is whether the manufacturer releases their proprietary firmware with a license that allows the distros to redistribute it, or requires it to be directly downloaded from their website.
Intel is one of the better manufacturers, and its developers do the commits to get its iwfwifi FOSS driver included in mainline Linux and its iwlwifi/linux-firmware proprietary firmware included in linux-firmware.
The ath9k doesn’t have an embedded CPU like the later Atheros cards, so its WiFi can function without any firmware, but it generally functions better with the proprietary firmware. Its Bluetooth, however, requires the proprietary firmware in order to function.
It might be possible to reverse engineer some of the WiFi firmware that runs the WiFi card’s operating system, similar to what is being done with the Quectel modem in the PinePhone, but they haven’t figured out how to reverse engineer the radio functions. This article has some discussion of the legal and tech issues:
Its hard to know how difficult it will be until someone makes the attempt and starts figuring out all the issues involved. If the WiFi/BT card is running a stripped-down version of Linux, there is probably a lot that can be reversed engineered. From what I understand, the radio functions are likely to be harder to reverse engineer than the WiFi/BT’s operating system.
But isn’t the real issue for Purism whether the device requires firmware at all to reside within Linux?
Realistically, noone expects the manufacturer to release firmware as FOSS but as long as the firmware hides permanently inside the WiFi device (e.g. on board flash storage or e.g. on board non-flashable storage), it should be OK for Purism.
Conversely, if the WiFi device requires firmware to be loaded at boot time then that is not something that can be fixed in software (probably?!?). So in this scenario the only option would be to reverse engineer the firmware until it could be considered open source (and then it would be OK for it to reside within Linux).
So my understanding is that these Intel cards may well work fine on the Librem 14 but you have to compromise a little if you want to use one.
This is not entirely true. The ATH9k is based around a Tensilica Xtensa core and has a firmware, but this firmware resides on chip and not as blob in userspace. The Ar3k, which is the Bluetooth part, does not require a firmware but a rather small parameter blob. It can also use an external firmware to update parts of the built-in ROM (often called “RAM patch”) but that’s not strictly necessary. Also the parameter block is not strictly necessary. I once patched the load of it out of the kernel and Bluetooth will then work with the hardwired parameters instead - though YMMV since some Bluetooth modules (I do not know if the QCNFA222 does) use such kind of parameters to e.g. control WIFi/Bluetooth coexistence, which could result in only either one of the two working at a given time.
I am not so sure about this patent argument. This was one that was also given for years for GPUs and why manufacturers would not create free drivers for them. Look what happened - nothing. By now we have blob free drivers for quite a bunch of GPUs, for some others free drivers with blobs and no huge patent litigation has happened.
Yes, all radio stuff is a heavy patent mine field area but these firmware or drivers do not contribute much to proofs for or against patent infringement in practice, it seems.
I have talked to many manufacturers over the course of the past years and in most cases not releasing more as open source has more to do with unproven fear of everything and less concrete risk assessment. Very often you also encounter the “Oh, then we loose our business advantage!” argument, which IMHO is plain false. I do not know of any case in the industry where open source would have been detrimental for a chip maker’s business. Not happening.
But there are more profound reasons one could give, especially for radios. The firmware is usually the last barrier before full control over the radio, especially the transmitting part. All radio is regulated, especially radio transmissions are pretty heavily regulated. Even the 2.4GHz and 5GHz spectrums are ISM spectrums for free use they are not unregulated. Manufacturers must make sure that regulations are met. In the recent years more regulations and laws or law like regulations have been passed that require manufacturers to make sure that users can not bypass anything that prevents them from regulatory compliance. Since you do not and in most cases can not safely prevent this in hardware, you do this in software, namely the firmware.
As far as I know all the radio parts are still not open and there is also little intention to do so. What was done is to hack open the Linux system that is actually running on the modem module - which is cool! But this is still far from “reverse engineering the firmware”. All the radio and a lot of other parts are still used as-is with blobs and that likely not to change.
WiFi cards in contrast are much more primitive / simpler than a cellular modem so IMHO that can not be really compared.
The only free radio “firmware” implementation I know of is the NIMBLE BLE Bluetooth stack which implements everything for the Nordic semiconductor nRF52xxx chips, including full radio control - in contrast e.g. to the famous ESP chips where SDKs like Arduino or the Espressif native IDK/ADK include larger binary only libraries which implement the radio engine and AFAIK there is no open source re-implementation for these yet.
I think we have to arrange ourselves with binary blob firmares somehow. I frankly do not mind them, as long as some requirements are met:
firmware blobs must not be executed on the main CPU that also runs the operating system - that would be a string security concern
firmware blobs must come with a perpetual license to redistribute the blob as part of anything without any limitation - else OS distributions get a problem
If these two are met, I have no problem with putting a firmware blob onto my SSD and have the kernel load it into the hardware before using it. I would even prefer this over any solution with the firmware hidden in some obscure piece of hardware which I eventually can not update - and also not have a look at that blob, it’s hidden away from my eyes. I have seen firmware licenses that I would not accept, that e.g. limit redistribution to only as part of a bundle with the manufacturer’s hardware. That’s ridiculous and would severely harm distributions, that’s unacceptable. I even think that some of the firmware files in kernel.org’s firmware repo have such a license though no one cares. But it is a dangling sword over everyone’s head and I do not like that. There is also no good reason to limit distribution like that.
Interesting. I was going off the footnote in the Wikipedia page that says this about the ath9k:
However, when I read the original article, which is an interview with Theo de Raadt of OpenBSD in 2004, I see that he was probably talking about Atheros cards before the ath9k series.
I will correct the Wikipedia article’s footnote. It is sad that there isn’t a newer WiFi/BT chip that Purism can use. (The ath9k driver was added to Linux in Oct 2008.) @nicole.faerber, I recall that you posted that Purism was trying to find a better alternative. Any hope on that front?
I have been asking vendors (chip makers and their distributors) for years now and got nothing. They are not even interested to listen to arguments pointing out the possible problems, so I pretty much gave up active research and am just watching the market.
I can to some extent also understand their position. It is merely impossible to have no CPU (alike) core on the chip since you have to handle a lot of stuff on the radio baseband side with as little as possible latency. You can not offload everything to the host CPU which would cause a lot of bus traffic - not necessary bus traffic. So stuff like encryption (e.g. WPA) and other parts should reasonably be handled on the card / hardware itself directly. But then again this becomes a bit more complex and if complexity rises the chance of bugs rises too. So you need ways to fix issues in the field - else you would have to replace the hardware. This leads of course to the idea to have it as a piece of code (the CPU core is there anyway) which can be updated/replaced at runtime - and here you have it, the firmware blob.
And in all honesty I do not totally believe in the “NO BLOBS IN USERSPACE !” rule. If we have the binary code cast in silicone (=ROM) on the chip or having it as a file on the disk to me does make a big difference, as long as three rules are met:
the blob must come with a perpetual license that allows copying and redistributing the blob without any limitation
the blob must not include actual code (or similar things like scripts (BPF comes to mind too)) that needs to get executed or evaluated by the host system
the runtime system must be able to check the integrity of the blob so that malicious injection of manipulated blobs can be prevented / detected (easy to solve by user signatures, not provider signatures, I want to be in control, not having to rely on some obscure factory holding signing keys)
As long as these three rules are met I would even say that this kind of blob is favorable compared to blobs hidden away from users in some hardware ROM. If the blob is out in the open on your disk you can easily update them (which can be important for security and privacy as well), you can make sure that a version you deemed good can not be altered without you knowing and you can start to analyze the blob.
And, as we have seen, one generation of WPA can get cryptographically broken and so the next generation of WPA is specified, and sometimes it is possible to get the next generation of security by upgrading the firmware (rather than having to throw away your WiFi card).
I guess you could include that as “bugs”.
In theory Purism’s extended boot integrity protection can handle that i.e. if you choose to cover things on the root file system (in addition to the standard choice of covering things on the boot file system).
And it’s not only that. We also have seen implementation bugs in WiFi cards’ firmware which compromised WPA2 security since the card plays a major role in generating the keys used. Only a firmware update was able to fix this. If the firmware would have been cast in stone (=ROM) you would either have to toss away the hardware (not good for the environment) or live with a compromised system.
But this example also shows how important it is that users get control over that firmware too and can make sure that only a firmware they deem good is used. Else a malicious actor could introduce a firmware into the system that has e.g. a known vulnerability and exploit this to get access to a system or communication. And WiFi is only one example here, similar attacks are thinkable for a variety of hardware.
“firmware blobs must not be executed on the main CPU that also runs the operating system - that would be a string security concern”
Does it mean proprietary firmware packages on Linux distributions like Debian can run malicious code on the computer CPU? There is no security in Linux to prevent that?
By the way, when I installed Debian 12 LXQt ISO with the graphical install, it installed many proprietary firmware packages that were not needed and without my consent.
Is it possible that proprietary firmware included in Debian default installation contains spyware that hides somewhere else (like viruses that are able to duplicate themselves in several locations) even after uninstalling all unnecessary packages we see with the command vrms? I was wondering if I need to reinstall the whole operating system without proprietary firmware to have a clean installation.
But I guess this would only be technically possible with software packages, not firmware packages.
There are two questions: Does such firmware exist? And which precautions does Linux provide?
The rules I formulated in that post you refer to were meant a bit broader, not just firmware, but all kinds of blobs, which could also include binary only drivers that are loaded as modules into the kernel or binary only libraries which can live somewhere between kernel space and user space. All that should IMHO not be acceptable since these can compromise the system.
Concerning precautions by the kernel or system, well, that’s not so easy since in general the kernel and Linux community wants to support such use cases - although of course no one really wants it, but it should at least be possible. So the kernel does not prevent this in any way. There are precautions like IOMMU and things that can help a bit but as soon as a driver runs code in kernel space as loadable module it has a lot of privileges.
Strictly speaking about firmware and the Linux loadable firmware interface I am fairly sure that it does not directly support loading kernel space executable code but I am also quite sure that it could be cleverly exploited to do so, if someone would write a malicious driver to do that. But then you have already malicious code (the malicious driver) in kernel space and then loading that firmware piece is just the icing on the cake.
