Non-Freedom Firmware and Drivers

From Kicksecure
< Dev
Jump to navigation Jump to search

Your support makes
all the difference!

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 10 year success story and maybe 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 blobsarchive.org. Most convincing arguments start in comment 11archive.org:

It talks about https://packages.debian.org/bullseye/firmware-linux-nonfreearchive.org

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.htmlarchive.org

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]

Tails - The Amnesic Incognito Live System - Position[edit]

Tails developer intrigeri wrotearchive.org:

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.

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 making Linux Mint sign a license contract with Canonicalarchive.org and introducing Amazon search lens and data leaksarchive.org. 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 their 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 nonfree blobs can be argued from multiple perspectives.

A) The security argument: Which got refuted above..

B) The philosophical stance against ever shipping any kind of shipping of anything nonfree. Argument of being the best possible Freedom Software vendor.

C) Argument of negative adaption: The argument goes that the number of users would decrease due to fallout from being tainted with nonfree software due to bad reputation, word of mouth, and media reporting.

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 sacrifice shipping 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 nonfree 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 will support command line parameters 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-installerarchive.org (not same drivers as firmware-b43legacy-installer) [download during installation by package maintainer script]
  • firmware-linux
  • firmware-ralink
  • firmware-b43legacy-installerarchive.org (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 considered.

Nvidia's closed drivers have been confirmed to contain telemetry baked into them. [3] The open Noveau stack is an alternative for those running Nvidia GPUs. Noveau is included in mainline Linux.

Proprietary drivers require the continued support of the vendor for compatibility with the latest Linux version. Withdrawal of support at 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 for continued functioning of their hardware at expense of security updates. Android is a sad example of this epidemic. Also the closed driver module cannot be patched for security problems itself or even have the fixes legally redistributable even if it was.

Forum Discussion[edit]

https://forums.whonix.org/t/whonix-host-nonfree-blobs-firmware-linux-nonfree/7251archive.org

See Also[edit]

Footnotes[edit]

  1. ↑ 1.0 1.1 By definition there are no built-in nonfreedom firmware blobs to begin with due to absence of nonfreedom hardware design.
  2. ↑ https://salsa.debian.org/debian/b43-fwcutter/blob/master/debian/firmware-b43-installer.postinstarchive.org
  3. ↑ https://forums.developer.nvidia.com/t/is-there-telemetry-in-nvidias-proprietary-linux-drivers/46414archive.org "So NVIDIA customer care has informed me that all latest drivers from them, including Linux drivers contain telemetry."
Unfinished: This wiki is a work in progress. Please do not report broken links until this notice is removed, use Search Engines First and contribute improving this wiki.
Retrieved from "https://www.kicksecure.com/w/index.php?title=Dev/nonfree&oldid=69983"