Firmware and Debian

There has been a flurry of activity on the Debian mailing lists ever since Steve McIntyre raised the issue of including non-free firmware as part of official Debian installation images.

Firstly I should point out that I am in complete agreement with Steve’s proposal to include non-free firmware as part of an installation image. Likewise I think that we should have a separate archive section for firmware. Because without doing so it will soon become almost impossible to install onto any new hardware. However, as always the issue is more nuanced than a first glance would suggest.

Lets start by defining what is firmware?

Firmware is any software that runs outside the orchestration of the operating system. Typically firmware will be executed on a processor(s) separate from the processor(s) running the OS, but this does not need to be the case.

As “Debian” we are content that our systems can operate using fully free and open source software and firmware. We can install our OS without needing any non-free firmware.

This is an illusion!

Each and every PC platform contains non-free firmware…

It may be possible to run free firmware on some Graphics controllers, Wi-Fi chip-sets, or Ethernet cards and we can (and perhaps should) choose to spend our money on systems where this is the case. When installing a new system we might still be forced to ‘hold our nose’ and install with non-free firmware on the peripheral before we are able to upgrade it to FLOSS firmware later – if this is exists or is even possible to do so. However after the installation we are running a full FLOSS system in terms of software and firmware.

We all (almost without exception) are running propitiatory firmware whether we like it or not.

Even after carefully selecting graphics and network hardware with FLOSS firmware options we still haven’t escaped from non-free-firmware. Other peripherals contain firmware too – each keyboard, disk (SSDs and Spinning rust). Even your USB memory stick that you use to contain the Debian installation image contains a microcontroller and hence also contains firmware that runs on it.

1. Much of this firmware can not even be updated.
2. Some can be updated, but is stored in FLASH ROM and the hardware vendor has defeated all programming methods (possibly circumnavigated with a hardware mod).
3. Some of it can be updated but requires external device programmers (and often the programming connections are a series of test points dotted around the board and not on a ‘header’ in order to make programming as difficult as possible).
4. Sometimes the firmware can be updated from within the host operating system (i.e. Debian)
5. Sometimes, as Steve pointed out in his post, the hardware vendor has enough firmware on a peripheral to perform basic functions – perhaps enough to install the OS, but requires additional firmware to enable specific feature (i.e. higher screen resolutions, hardware accelerated functions etc.)
6. Finally some vendors don’t even bother with any non-volatile storage beyond a basic boot loader and firmware must be loaded before the device can be used in any mode.

What about the motherboard? If we are lucky we might be able to run a FLOSS implementation of the UEFI subsystem (edk2/tianocore for example), indeed the non AMD64/i386 platforms based around ARM, MIPS architectures are often the most ‘free’ when it comes to firmware.

What about the microcode on the processor? Personally I wasn’t aware that that this was updatable ‘firmware’ until the Spectre and Meltdown classes of vulnerabilities arose a few years back.

So back to Debian images including non-free firmware.

This is specifically to address the last two use cases mentioned above, i.e. where firmware needs to be loaded to achieve a minimum functioning of a device. Although it could also include motherboard support, and microcode as well.

As far as I can tell the proposal exists for several reasons:

#1 Because some ‘freely distributable’ firmware is required for more and more devices, in order to install Debian, or because whilst Debian can be installed a desktop environment can not be started or fully function

#2 Because frankly it is less work to produce, test and maintain fewer installation images – As someone who performs tests on our images, this clearly gets my vote :-)

and perhaps most important of all..

#3 Because our least experienced users, and new users will download an official image and give up if things don’t “just work”^TM

Steve’s proposal option 5 would address theses issues and I fully support it.

I would love to see separate repositories for firmware and firmware-none free. Additionally to accompany firmware non-free I would like to have information on what the firmware actually does. Can I run my hardware without it, what function(s) are limited without the firmware, better yet is there a FLOSS equivalent that I can load instead? Is this something that we can present in Debian installer? I would love not to “require” non-free firmware, but if I can’t, I would love if DI would enable a user to make an informed choice as to what, if any, firmware is installed.

Should we be requesting (requiring?) this information for any non-free firmware image that we carry in the archive?

Finally lets consider firmware in the wider general case, not just the case where we need to load firmware from within Debian each and every boot.

Personally I am annoyed whenever a hardware manufacturer has gone out of their way to prevent firmware updates. Lets face it software contains bugs, and we can assume that the software making up a firmware image will as well.

Critical (security) vulnerabilities found in firmware, especially if this runs on the same processor(s) as the OS can impact on the wider system, not just the device itself. This will mean that, without updatable firmware, the hardware itself should be withdrawn from use whilst it would otherwise still function. By preventing firmware updates vendors are forcing early obsolescence in the hardware they sell, perhaps good for their bottom line, but certainly no good for users or the environment.

Here I can practice what I preach. As an Electronic Engineer / Systems architect I have been beating the drum for In System Updatable firmware for ALL programmable devices in a system, be it a simple peripheral or a deeply embedded system. I can honestly say that over the last 20 years (yes I have been banging this particular drum for that long) I have had 100% success in arguing this case commercially. Having device programmers in R&D departments is one thing, but that is additional cost for production, and field service. Needing custom programming headers or even a bed of nails fixture to connect your target device to a programmer is more trouble than it is worth. Finally, the ability to update firmware in the field means that you can launch your product on schedule, make a sale and ship to a customer even if the first thing that you need to do is download an update. Offering that to any project manager will make you very popular indeed.

So what if this firmware is non-free? As long as the firmware resides in non-volatile media without needing the OS to interact with it, we as a project don’t need to carry it in our archives. And we as principled individuals can vote with our feet and wallets by choosing to purchase devices that have free firmware.

But where that isn’t an option, I’ll take updatable but non-free firmware over non-free firmware that can not be updated any day of the week.

Sure, the manufacture can choose to no longer support the firmware, and it is shocking how soon this happens – often in the consumer market, the manufacture has withdrawn support for a product before it even reaches the end user (In which case we should boycott that manufacture in future until they either change their ways of go bust). But again if firmware can be updated “in system” that would at least allow the possibility of open firmware to arise. Indeed the only commercial case I have seen to argue against updatable firmware has been either for DRM, in which case good – lets get rid of both, or for RF licence compliance, and even then it is tenuous because in this case the manufacture wants ISP for its own use right up until a device is shipped out the door, typically achived by blowing one time programmable ‘fuse links’.