Steve McIntyre: Firmware - what are we going to do about it?
TL;DR: firmware support in Debian sucks, and we need to change
this. See the "My preference, and rationale" Section below.
In my opinion, the way we deal with (non-free) firmware in Debian is a
mess, and this is hurting many of our users daily. For a long time
we've been pretending that supporting and including (non-free)
firmware on Debian systems is not necessary. We don't want to have
to provide (non-free) firmware to our users, and in an ideal world we
wouldn't need to. However, it's very clearly no longer a sensible path
when trying to support lots of common current hardware.
Background - why has (non-free) firmware become an issue?
Firmware is the low-level software that's designed to make
hardware devices work. Firmware is tightly coupled to the hardware,
exposing its features, providing higher-level functionality and
interfaces for other software to use. For a variety of reasons, it's
typically not Free Software.
For Debian's purposes, we typically separate firmware from
software by considering where the code executes (does it run on a
separate processor? Is it visible to the host OS?) but it can be
difficult to define a single reliable dividing line here. Consider the
Intel/AMD CPU microcode packages, or the U-Boot firmware packages as
examples.
In times past, all necessary firmware would normally be included
directly in devices / expansion cards by their vendors. Over time,
however, it has become more and more attractive (and therefore more
common) for device manufacturers to not include complete firmware
on all devices. Instead, some devices just embed a very simple set
of firmware that allows for upload of a more complete firmware "blob"
into memory. Device drivers are then expected to provide that blob
during device initialisation.
There are a couple of key drivers for this change:
- Cost: it's typically cheaper to fit smaller flash memory (or no flash at all) onto a device. The cost difference may seem small in many cases, but reducing the bill of materials (BOM) even by a few cents can make a substantial difference to the economics of a product. For most vendors, they will have to implement device drivers anyway and it's not difficult to include firmware in that driver.
- Flexibility: it's much easier to change the behaviour of a device by
simply changing to a different blob. This can potentially cover lots
of different use cases:
- separating deadlines for hardware and software in manufacturing (drivers and firmware can be written and shipped later);
- bug fixes and security updates (e.g. CPU microcode changes);
- changing configuration of a device for different users or products (e.g. potentially different firmware to enable different frequencies on a radio product);
- changing fundamental device operation (e.g. switching between RAID and JBOD functionality on a disk controller).
- Going back 10 years or so, most computers only needed firmware uploads to make WiFi hardware work.
- A growing number of wired network adapters now demand firmware uploads. Some will work in a limited way but depend on extra firmware to allow advanced features like TCP segmentation offload (TSO). Others will refuse to work at all without a firmware upload.
- More and more graphics adapters now also want firmware uploads to provide any non-basic functions. A simple basic (S)VGA-compatible framebuffer is not enough for most users these days; modern desktops expect 3D acceleration, and a lot of current hardware will not provide that without extra firmware.
- Current generations of common Intel-based laptops also need firmware uploads to make audio work (see the firmware-sof-signed package).
- Building, testing and publishing two sets of images takes more effort.
- We don't really want to be providing non-free images at all, from a philosophy point of view. So we mainly promote and advertise the preferred official free images. That can be a cause of confusion for users. We do link to the non-free images in various places, but they're not so easy to find.
- Using non-free installation media will cause more installations to use non-free software by default. That's not a great story for us, and we may end up with more of our users using non-free software and believing that it's all part of Debian.
- A number of users and developers complain that we're wasting their time by publishing official images that are just not useful for a lot (a majority?) of users.
- Keep the existing setup. It's horrible, but maybe it's the best we can do? (I hope not!)
- We could just stop providing the non-free unofficial images altogether. That's not really a promising route to follow - we'd be making it even harder for users to install our software. While ideologically pure, it's not going to advance the cause of Free Software.
- We could stop pretending that the non-free images are unofficial, and maybe move them alongside the normal free images so they're published together. This would make them easier to find for people that need them, but is likely to cause users to question why we still make any images without firmware if they're otherwise identical.
- The images team technically could simply include non-free into the official images, and add firmware packages to the input lists for those images. However, that would still leave us with problem 3 from above (non-free generally enabled on most installations).
- We could split out the non-free firmware packages into a new non-free-firmware component in the archive, and allow a specific exception only to allow inclusion of those packages on our official media. We would then generate only one set of official media, including those non-free firmware packages. (We've already seen various suggestions in recent years to split up the non-free component of the archive like this, for example into non-free-firmware, non-free-doc, non-free-drivers, etc. Disagreement (bike-shedding?) about the split caused us to not make any progress on this. I believe this project should be picked up and completed. We don't have to make a perfect solution here immediately, just something that works well enough for our needs today. We can always tweak and improve the setup incrementally if that's needed.)
- Along with adding non-free firmware onto media, when the installer (or live image) runs, we should make it clear exactly which firmware packages have been used/installed to support detected hardware. We could link to docs about each, and maybe also to projects working on Free re-implementations.
- Add an option at boot to explicitly disable the use of the non-free firmware packages, so that users can choose to avoid them.
- Cyril Brulebois
- Matthew Garrett
- David Leggett
- Martin Michlmayr
- Andy Simpkins
- Neil Williams