Non-Freedom Firmware and Drivers
Donate
This page discusses the security arguments for and against shipping non-freedom firmware blobs and drivers.
Nonfree Firmware[edit]
Security Argument[edit]
On the Tails issue tracker there is an interesting discussion about shipping nonfree firmware blobs
. Most convincing arguments start in comment 11:
It talks about https://packages.debian.org/bookworm/firmware-linux-nonfree
Bold / italic added.
There is no evidence that anything in the Linux kernel is spyware. The firmware blobs are loaded into devices which need them to function. The alternative is for them to be present in the device from the beginning, as I explain later.
Here, for example, almost a year ago, all you summarily refused to discuss this issue:
https://web.archive.org/web/20210416183217/https://mailman.boum.org/pipermail/tails-support/2016-March/000345.html
In that thread, you linked to a paper on DMA malware. Note that the blobs in question are typically firmware for PCI devices, usually NICs. DMA malware works by abusing the bus master bit and becoming bus master, allowing DMA requests. Most modern UEFI/BIOS come with ACPI tables built in, which contains one table, the DMAR table, which can be used by the IOMMU to restrict the addresses a device with bus master is allowed to access. If you boot with `intel_iommu=on` or `amd_iommu=force` , and your DMAR table is valid, then DMA malware, if it is loaded after the IOMMU enforces its restrictions, is effectively crippled. Tails unfortunately does not enable the IOMMU by default, as it breaks a lot of hardware with broken DMAR tables (BIOS vendors suck, don't they?), but it's trivial to enable it yourself.
Being free software, and being endorsed by the Free Software Foundation are different things. By many definitions, something can still be FOSS even if it distributes blobs which run on NICs for example, as long as those blobs do not run on the CPU alongside the kernel. In the case that they run as firmware, they are effectively no different than an updatable ROM. If you select an FSF-endorsed distro, you are still running the same type of blob. The only difference is that it is bunt into your hardware, not in the kernel. If there is a backdoor, as you worry about, it will not be neutered just because it is distributed through a ROM rather than loaded by the kernel. If anything, loading through the kernel is safer, because people are more willing to reverse engineer it or audit it (yes, closed source blobs can be reverse engineered and audited), whereas something burnt into a ROM will likely never be touched.
That is primarily due to philosophical reasons, and possibly misunderstandings. I can completely understand the philosophical ideology behind "Fine, let the hardware manufacturers distribute the blobs, but I don't want my distro to take part in it at all!", but you'd be deluding yourself to say that it improves your security. The only way to improve your security (or at least the openness of the whole software ecosystem) is to get the firmware/ROM source to be open, not simply be content with it being burnt into your hardware.
But in the end, if you're really worried about covert backdoors on this level, why are you singling out what really amounts to just NIC firmware, most of which boils down to just a few brands? There's so much more which puts people at risk if an adversary with these capabilities is after them. After all, the Linux kernel is huge, takes patches from many people, and is poorly audited. Adding a mistake (bugdoor) would not be hard. I don't mean something obvious like `if (uid = 0)` from the old `wait4()` backdoor attempt either. There's also the fact that, no matter how open your software is, you're running on entirely closed hardware. Who cares about the Intel Manageability Engine or the Embedded Controller Firmware when the entirety of the immensely complex processor is closed.
Now start porting Tails to seL4 or INTEGRITY-178B, and run it entirely on OpenSPARC, and then you can be happy. :P
But seriously though, if you're this passionate about this, learn how to use `r2` and get to reverse engineering those blobs.
Not distributing firmware in the kernel does not affect the risk of "spyware" whatsoever. If there is going to be a backdoor, it can also exist burnt into the ROM. Not having firmware blobs in the kernel does not mean they do not still exist. It just means they are distributed in a different way. Do you think that a Realtek NIC that does not need uploaded firmware, but does use a burnt in ROM, cannot have a backdoor in its built in firmware, but a Broadcom NIC that requires firmware and does not use burnt in ROM can?
Furthermore, all the blobs in the kernel are only loaded for the people who are using the specific hardware which requires it. If you are not using the tg3 driver, you will not be loading the tg3 firmware. So if someone uses tg3, they will not be able to use a "libre" Tails. If someone uses r8192, they won't be using firmware blobs for their NIC regardless of whether they use a "libre" Tails or current Tails. Simply put, people who do not use blob-requiring hardware will not be using blobs, regardless. People who do need blobs will either be using nothing , or an NIC that loads blobs. Those people are screwed anyway, whereas people who are using NICs which don't need blobs don't have to worry.
Other Projects[edit]
Debian[edit]
Debian official image nowadays includes non-freedom firmware.
The Debian official media may include firmware that is otherwise not part of the Debian system to enable use of Debian with hardware that requires such firmware.https://www.debian.org/vote/2022/vote_003#texte
The winners Option 5 "Change SC for non-free firmware in installer, one installer"https://www.debian.org/vote/2022/vote_003#outcome
Note: SC stands for the Debian Social Contract.
Sources:
- https://lwn.net/Articles/910065/
- https://www.tomshardware.com/news/debian-includes-proprietary-code
- https://cdimage.debian.org/images/unofficial/non-free/images-including-firmware/
Tails - The Amnesic Incognito Live System - Position[edit]
Tails developer intrigeri wrote:
We have actual users. If they can't use Tails on their current, real-world hardware, then likely they'll use something else, that has just the same amount of binary firmware blobs, except it won't have any of Tails properties that some people find worthwhile.
Qubes[edit]
- https://www.qubes-os.org/faq/#is-qubes-os-free-and-open-source-software
- https://www.qubes-os.org/faq/#will-qubes-seek-to-get-certified-under-the-gnu-free-system-distribution-guidelines-gnu-fsdg
- https://forum.qubes-os.org/t/qubes-debian-templates-have-non-free-contrib-apt-by-default/13035/103
Argument of Negative Adaption[edit]
I believe that negative publicity can still generate attention and attract new users. In fact, bad news is often better than no news at all. This is particularly true for Kicksecure, which is still far from reaching its maximum popularity and user base.
It is worth noting that Ubuntu has faced bad publicity due to its nonfree practices in the past, such as requiring Linux Mint to sign a license contract with Canonical and introducing the Amazon search lens and data leaks. Despite this, Ubuntu remains the most popular Linux distribution.
Similarly, Tails, another popular privacy-oriented operating system, includes firmware-linux-nonfree by default, but this decision did not significantly decrease its user base. The criticism was limited to a small number of users who expressed their concerns on the Tails issue tracker and mailing list several years ago.
Overview of Arguments[edit]
The stance against non-freedom blobs can be argued from multiple perspectives.
- A) The security argument: which was refuted above.
- B) The philosophical argument: a stance against ever including any kind of non-freedom software. This is based on striving to be the best possible Freedom Software vendor.
- C) Argument of negative adaption: the claim that the number of users would decrease due to fallout from being associated with non-freedom software, resulting in bad reputation, word of mouth, and negative media coverage.
Comparison Table[edit]
Table: Comparison Table - (non)Freedom Hardware Design vs (non)Freedom Firmware installed
| Thing | nonfreedom hardware design with nonfreedom firmware installed
|
nonfreedom hardware design without nonfreedom firmware installed
|
Freedom Hardware Design with nonfreedom firmware installed
|
Freedom Hardware Design without nonfreedom firmware installed
|
built-in provided nonfreedom firmware blobs not active in kernel (security argument)
|
Yes | No | Yes [1] | Yes [1] |
nonfreedom firmware package-provided nonfreedom firmware blobs not active in kernel (security argument)
|
No | Yes | Yes | Yes |
no nonfreedom software active (security argument)
|
No | No | Yes | Yes |
boot medium entirely clean from nonfreedom software (philosophical argument)
|
No | Yes | No | Yes |
system entirely clean from nonfreedom software (philosophical argument)
|
No | No | No | Yes |
Kicksecure Lead Developer Position[edit]
Some people argue that it's better to ship something broken, insecure, or unusable for most users than to compromise on Freedom Software principles. While I believe in the importance of Free Software, I don't think it's practical to adhere to these principles to the point of sacrificing usability and functionality.
That said, I'm not a non-freedom software minimalist like RMS, nor am I a Freedom Software maximalist like RMS. I believe in finding a practical balance between the two.
Therefore, when considering practicality vs. Freedom Software principles, I've decided that firmware-linux-nonfree will be installed by default on Kicksecure Host. This decision ensures that our users have a better out-of-the-box experience and that we can support a wider range of hardware.
However, it is understood that some users may prefer a completely Free Software system. That's why Kicksecure's build script supports command-line parameters --freedom true to skip the installation of any non-freedom software, making it easy to create custom builds or forks that adhere to Freedom Software principles.
Overview of Packages[edit]
These will not be all shipped in Kicksecure. This is only a notepad for developers to decide which packages to ship and which ones not.
- firmware-adi - deprecated transitional package
- firmware-intelwimax
- firmware-myricom
- firmware-amd-graphics
- firmware-ipw2x00
- firmware-netronome
- firmware-ath9k-htc
- firmware-ivtv
- firmware-netxen
- firmware-ath9k-htc-dbgsym
- firmware-iwlwifi
- firmware-qcom-media
- firmware-atheros
- firmware-libertas
- firmware-qlogic
- firmware-b43-installer (not same drivers as firmware-b43legacy-installer) [download during installation by package maintainer script]
- firmware-linux
- firmware-ralink
- firmware-b43legacy-installer (not same drivers as firmware-b43-installer) [download during installation by package maintainer script] [2]
- firmware-linux-free
- firmware-realtek
- firmware-bnx2
- firmware-linux-nonfree
- firmware-samsung
- firmware-bnx2x
- firmware-microbit-micropython
- firmware-siano
- firmware-brcm80211
- firmware-microbit-micropython-dl
- firmware-ti-connectivity
- firmware-cavium
- firmware-microbit-micropython-doc
- firmware-zd1211
- firmware-intel-sound
- firmware-misc-nonfree
- amd64-microcode
- intel-microcode
Nonfree Drivers[edit]
Closed source drivers pose privacy and security risks and are therefore unacceptable. With the wide selection of PC hardware that supports the FLOSS-only mainline kernel, we can make this decision with pragmatism in mind.
Nvidia's closed drivers have been confirmed to contain telemetry baked into them.[3] The open Nouveau stack is an alternative for those running Nvidia GPUs. Nouveau is included in mainline Linux.
Proprietary drivers require the continued support of the vendor for compatibility with the latest Linux versions. Withdrawal of support at the end of product life cycles, or because it is not financially desirable for the companies involved, means users will be stuck running ancient kernels in perpetuity to maintain hardware functionality at the expense of security updates. Many Google Android OEMs are a sad example of this epidemic. Also, the closed driver module cannot be patched for security problems, nor can the fixes be legally redistributed even if available.
Forum Discussion[edit]
https://forums.whonix.org/t/whonix-host-nonfree-blobs-firmware-linux-nonfree/7251
See Also[edit]
- Why Kicksecure is Freedom Software
- Avoid non-freedom software
- Kicksecure Policy On Non-Freedom Software
- Context: Kicksecure Host Operating System Development
- Purpose of forum thread Whonix host - nonfree blobs - firmware-linux-nonfree: keeping the discussion of nonfree vs free out of above thread.
- Non-Purpose of this: non-freedom software in Kicksecure VMs (there is none but if you think there is another thread
- Related: Kicksecure and Free System Distribution Guidelines (GNU FSDG) and Kicksecure Policy On Non-Freedom Software
Footnotes[edit]
- ↑ 1.0 1.1 By definition, there are no built-in
nonfreedom firmwareblobs to begin with due to the absence ofnonfreedom hardware design. - ↑
https://salsa.debian.org/debian/b43-fwcutter/blob/master/debian/firmware-b43-installer.postinst
- ↑ https://forums.developer.nvidia.com/t/is-there-telemetry-in-nvidias-proprietary-linux-drivers/46414 "So NVIDIA customer care has informed me that all latest drivers from them, including Linux drivers contain telemetry."
A secure by default operating system with the latest security research in place.
At
Kicksecure we value freedom and trust, supporting Open Source and Freedom Software
2012-
2025 ENCRYPTED SUPPORT LLC
We believe security software like Kicksecure needs to remain Open Source and independent. Would you help sustain and grow the project? Learn more about our 13 year success story and maybe DONATE!