McIntyre: Firmware - what are we going to do about it?
source link: https://lwn.net/Articles/891767/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 7:34 UTC (Tue) by jorgegv (subscriber, #60484) [Link]
We unconsciously think of our current computers as a Big CPU connected to some little hardware "bricks", and then decide that the software inside those bricks is somehow inferior, give It a different name, and apply different policies to It.
But the reality is that our laptop is indeed a network of hundreds of computers, each of them running their own software. And free software principales should be applied to all of them, not just to "the Big one".
Since we have made the distinction and we apply the principles to one software class, but not quite to the other one, hardware manufacturers have shifted to shipping software of the latter class.
Being completely coherent is a tough Ride, as Debian is showing us...
I was shocked a few years ago when my Dell laptop offered me to upgrade the firmware of its USB controller... and It took about ten times longer than upgrading the BIOS!
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 7:50 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 9:02 UTC (Tue) by joib (subscriber, #8541) [Link]
To answer my first rhetorical question, because it would be immensely impractical. In reality we would have no free HW on which to run our free SW. So we're already compromising on our "purity". Non-free firmware is just one fairly small step along the continuum. And arguably, one which alienates people from free software ending up in a net loss for software freedom.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 11:18 UTC (Tue) by excors (subscriber, #95769) [Link]
Developing a patch for regular application software, starting with C and ending up with a usable binary, takes maybe a few minutes and costs nothing.
Developing a patch for an ASIC, starting with Verilog and ending up with a physical chip, takes maybe six months and costs a million dollars.
Developing a patch for firmware, on devices that allow installing firmware updates over some host-accessible interface (which is probably all of the interesting ones - anything that doesn't require occasional bug fixes isn't doing any complicated work), takes maybe a few minutes and costs nothing.
There's many orders of magnitude difference in the practicality of updating software and hardware, so it makes a lot of sense to treat them differently in terms of demanding users be given the tools and permissions to modify them. Firmware used to be somewhere in the middle in practicality, when it was in ROM and was much harder to update than software but much easier than hardware. But nowadays it's in flash or RAM and it's exactly the same level of practicality as software, because it _is_ software, just with a funny name for historical reasons.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 12:00 UTC (Tue) by mfuzzey (subscriber, #57966) [Link]
The "regular application in C" and "ASIC in Verilog" examples you mention are the two extremes.
For firmware the problem is that the source code is not available most of the time (non free firmware). So, in practice, "patching" the firmware requires understanding the existing firware well enough to do that (either as a binary partch or implementing a complete open source equivalent) without access to the original source code. This is possible (by reverse engineering) but is significantly harder than for regular application software and requires lots of time and experience (though if you have that it can mostly be done fairly cheaply).
Then there is the FPGA case which is similar to ASIC from the tools perspective but does not have the problem of huge cost. The problem today is that open source FPGA toolchains are not as advanced as the proprietary equivalents though things are improving.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 13:38 UTC (Tue) by farnz (subscriber, #17727) [Link]
Not forgetting the other axis on which there's a continuum; microcontrollers and FPGAs usually have configurable pin-outs, controlled by the firmware you load onto them. If you make a mistake with the configurable pin-out, you can cause the magic smoke to escape the chip, rendering it useless.
This is more of a risk with FPGAs than with microcontrollers, because FPGA bitstreams typically include the pin to I/O assignment as part of the configuration process, where microcontrollers have pin to I/O assignment done in code, and if you don't execute code to change the I/O assignment, you don't leave the "safe" reset state.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 14:48 UTC (Tue) by excors (subscriber, #95769) [Link]
(There's also a third issue of requiring code to be signed with a key that regular users can't use or replace, which seems very common for firmware but can apply to software too (e.g. dm-verity on Android) so that's probably a separate discussion.)
Reverse-engineering and patching a firmware binary that runs on some coprocessor isn't fundamentally any harder than reverse-engineering and patching a binary kernel module that does equivalent work on the main CPU. Or if you have source code for both, they're still just as easy as each other. The classification as 'firmware' isn't what makes the difference.
From a Free Software perspective, why is it so much more important to let users modify code running on the main CPU than the code running on other chips (which may well have more processing power and memory than the main CPU, and be running their own full OS)? I like the description that "our laptop is indeed a network of hundreds of computers" because that makes it clear that the CPU _isn't_ special or privileged, it's just one component of many. (Arguably the laptop's physical boundary isn't even that special - my CPU is interacting with my GPU firmware which it previously downloaded from the internet, and it's also interacting with the proprietary Python code on LWN's web server, and LWN sends back some proprietary JavaScript to run on my CPU, and why should I care more or less about the GPU than about LWN?)
So, I don't think it's a coherent philosophy to say that Free Software principles apply to software but not firmware, because that's a meaningless boundary. It would be coherent to apply it to all code (both software and firmware, and arguably all the internet services you use) but not hardware, because there's a meaningful technical boundary in the unavoidably prohibitive cost of modifying hardware. It would also be coherent to accept a mix of Free and non-Free code, while strongly preferring Free code, without being bothered about what chip the code is running on. The latter seems like the only practical option that doesn't ignore the reality of modern computer design.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 19:09 UTC (Tue) by mfuzzey (subscriber, #57966) [Link]
Because code running on main CPU affects other code running on the main CPU far more than firmware does.
For example consider a GPU.
If it requires a closed source blob running on the main CPU (let's assume in user space to avoid getting into the legality or otherwise of closed source kernel modules) then that is going to restrict the users practical freedom in several ways:
* If they want to run Wayland and the blob only supports X11 out of luck.
* If they want to improve security of the system but using ASLR (that requires libraries be compiled PIC) out of luck if the blob isn't compiled that way.
* If they want to switch to a different processor architecture (Risc-V?) out of luck if there's no suitable blob version.
On the other hand none of those issues apply to any *firmware* that GPU may require, provided it works and is redistribuable the user can do all the above with a closed firware blob and an open userspace driver.
Of course if the firmware is buggy then the user can't fix that (easilly) in a blob.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 20, 2022 7:59 UTC (Wed) by marcH (subscriber, #57642) [Link]
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 16:39 UTC (Tue) by rgmoore (✭ supporter ✭, #75) [Link]
For firmware the problem is that the source code is not available most of the time (non free firmware). So, in practice, "patching" the firmware requires understanding the existing firware well enough to do that (either as a binary partch or implementing a complete open source equivalent) without access to the original source code. This is possible (by reverse engineering) but is significantly harder than for regular application software and requires lots of time and experience (though if you have that it can mostly be done fairly cheaply).
I'm not sure how true this is. Reverse engineering an application isn't easy, either. Look at how much work has gone into, for example, Libre Office in an attempt to reverse engineer and reproduce other office suites. It's relatively easy to modify an application once that front-end effort of creating a work-alike copy has been done, but getting to that point is a ton of effort. The big difference- and IMO one of the differences between free software and free firmware- is that the applications aren't tied nearly as tightly to particular hardware.
It's fairly standard to run the same software, without a recompile, on generation after generation of the same CPU architecture, or to port with a recompile from one architecture to another. It's less common for firmware to last across generations of the same architecture, and basically unheard of to port from one architecture to another. Just as a practical matter, that means we're a lot more likely to have to throw firmware away and start over from scratch than application software.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 18:05 UTC (Tue) by ejr (subscriber, #51652) [Link]
Documenting firmware and all its interfaces such that it can be modified requires at least multiple manuals.
Documenting an ASIC and all its interfaces requires at least a bookshelf.
And IME the cost of developing and maintaining documentation is not linear in its size.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 20:44 UTC (Tue) by chris_se (subscriber, #99706) [Link]
Only if the application is simple enough. I've never even looked at the source code of e.g. Firefox or LibreOffice in any meaningful amount of detail, and to be completely frank: for a simple enough peripheral it'd probably be way less work for me to modify a schematic in KiCad and order it via one of these PCB prototyping services that also include assembly than to understand enough of the abstractions and concepts behind the source code of large enough software projects I haven't looked at before in order to be able to change something there.
I don't disagree that modifying hardware requires more effort than modifying software of a similar complexity, but there's tons of hardware out there that's way, way simpler in design than a lot of widely used software packages.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 20, 2022 7:48 UTC (Wed) by marcH (subscriber, #57642) [Link]
It's not the cost of developing the patch, it's the fact that you cannot copy and deliver a "hardware upgrade" over the Internet because it is a physical object. That's the obvious and very clear line between hardware and software, hard to believe it needs to be explicited.
"Firmware" on the other hand has absolutely zero meaning, it's just software. Entire Android images including Linux kernel and userspace are routinely called "firmware images", go figure. I suspect firmware originally meant something like "software mostly hidden and invisible to humans" but that was very vague too.
Verilog that's been "printed out"
Posted Apr 19, 2022 12:56 UTC (Tue) by mikebenden (guest, #74702) [Link]
See https://github.com/litex-hub/linux-on-litex-rocket for a working proof of concept -- it can even boot 64-bit linux, and run its own HDL toolchain (yosys, nextpnr -- sort-of, slowly) :)
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 15:27 UTC (Tue) by pizza (subscriber, #46) [Link]
The reality is that *every* component of the system, from the keyboard to the display, and everything inbetween (network/wifi, nvme/sata storage, cpu, embedded controller, usb controller, audio codec, card reader, etc etc) relies on non-free embedded software/firmware. Whether or not it's embedded in mask ROM, flash, or uploaded at runtime, it's still non-free.
In the beginning of the Free Software movement, it was acceptable to incrementally replace parts of a proprietary system with Free components as they became available, if ever. Things are no different today; it does not advance the interest of Free Software to make said software effectively impossible to use on readily-available equipment.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 15:19 UTC (Tue) by pizza (subscriber, #46) [Link]
It is analogous to liquor stores using brown paper bags for their wares; if what's in the bag can't be seen then it's somehow more acceptable.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 17:33 UTC (Tue) by dmoulding (subscriber, #95171) [Link]
I couldn't agree more. It seems that many have lost sight of the situation that gave rise to the free software movement in the first place. Here's a relevant portion from the GNU Manifesto on the motivation for the whole undertaking:
> Why I Must Write GNU
> I consider that the Golden Rule requires that if I like a program I must share it with other people who like it. Software sellers want to divide the users and conquer them, making each user agree not to share with others. I refuse to break solidarity with other users in this way. I cannot in good conscience sign a nondisclosure agreement or a software license agreement.
Today's proprietary firmware doesn't match that old situation at all. First, nobody "likes" their firmware and feels an urge to share it with other users who might also like it. Consumers use firmware because it's necessary. Second, the manufacturers are not (generally) compelling users to sign license agreements or non-disclosure agreements with regard to the firmware. Probably most explicitly allow redistribution, right? (Otherwise the linux-firmware package couldn't exist in its current form).
Finally, the firmware isn't general purpose software designed to run on a general-purpose computing platform. In most cases, users simply could not arbitrarily change it to their liking because it generally must work with the hardware in very specific ways. Sure, it's possible in a lot of cases to tweak it here and there, but there are much stricter limits to what can be done with it due to the very nature of the hardware it runs on. And the vast, vast majority of users simply DO NOT CARE about how their firmware works, so long as it makes the hardware work the way it's supposed to. The motivation to "tweak" your firmware and "share" the derivative with other users who might like it simply does not exist like it does with general purpose software.
For these reasons, it fundamentally doesn't make sense to treat firmware the same as, say, a compiler, a shell, or a window system.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 18:17 UTC (Tue) by farnz (subscriber, #17727) [Link]
Note, though, that the defining incident was with printer firmware, not with general purpose software. RMS had access to a printer with imperfect firmware, and wanted it to send one more signal to the host so that it could notify all users of a problem; because the firmware was a binary blob, this was made hard for RMS to do, and he would not have been able to share the fixed version even if he reverse engineered the blob and created his own with the extra signal.
It does, however, illuminate a possible scale of "non-freeness". The worst case is locked down firmware where, as an end user, you cannot change the firmware even if you want to due to signatures and the like (Intel microcode updates). The least worst case is something where the firmware is written for a known architecture, is easy to disassemble, and there's no effort to stop you from changing the firmware freely.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 19, 2022 18:53 UTC (Tue) by dmoulding (subscriber, #95171) [Link]
But the firmware in a modern printer (or even a printer back then) is not generally responsible for things like job control and error notification. It's more likely to be responsible for things like:
* what temperature should the fuser reach before feeding the paper
* how much should the laser's input voltage be modulated to increase/decrease the charge on the drum
* speed control of rollers appropriate for DPI output
These are generally highly technical parameters that most users should not change (nor would want to, or might risk damaging the device if done improperly). And, I'd argue, it does *less* harm to the user that they cannot change the firmware that controls all that, than it does harm the end user if after installing Debian their printer won't print at all.
McIntyre: Firmware - what are we going to do about it?
Posted Apr 20, 2022 9:58 UTC (Wed) by farnz (subscriber, #17727) [Link]
The firmware in my printer, and in all the printers at my workplace, also has a full TCP/IP stack with IPv4 and IPv6 support, Ethernet, fax modem, LDAP, TLS, SMB, Apple Airprint, PDF rasterization, and many other bits beyond the low-level control you're describing. Sure, it does the low level control part as well, but from my point of view as a user of the device, that's just a component in a much larger firmware blob.
And the same applied to early Xerox laser printers, of the sort RMS is describing; the printer did not expose a low-level interface to the host computer, as cheap laser printers do today, and as dot matrix and inkjet printers have always done, but a high level interface where the host sends the printer a page description, and the printer reports when it's finished handling the page and is ready for the next page. All RMS wanted to do was to change that "finished this page" to "finished successfully", or "failed to print" so that the host software could send a message on "failed to print" to everyone.
Finally, your last paragraph applies to pretty much everything the kernel does - by swapping for a Linux kernel instead of the manufacturer-approved kernel (Windows, usually), you are risking damaging your device. For example, when I've been working on a (proprietary) system, I found by writing buggy code a SCSI command I could send to a drive that should have been rejected, but instead caused the drive to brick itself. Does this mean that users shouldn't be allowed to install a Linux kernel?
McIntyre: Firmware - what are we going to do about it?
Posted Apr 20, 2022 6:38 UTC (Wed) by eduperez (guest, #11232) [Link]
There is an explanation for that line of argument:
- I only use free software!
- What about firmware?
- I have created a distribution without blobs; I only use free software!
- What about firmware in ROM?
- Well, if the user cannot change it, then I will call it "hardware" instead of "software".
- What!?
- I only use free software!
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK