FSF updates its "fully free" distribution list

Posted Sep 15, 2009 19:23 UTC (Tue) by leromarinvit (subscriber, #56850)
In reply to: FSF updates its "fully free" distribution list by mjg59
Parent article: FSF updates its "fully free" distribution list

...if you prefer your firmware burned-in rather than loaded at runtime.

This, to me, shows how idiotic the anti-firmware argument really is. Modern hardware is going to require some kind of firmware, whether it is executable code for a built-in microcontroller or an FPGA bitstream. Any moderately complex piece of hardware is likely going to be designed that way. And with runtime loading, at least it can be easily exchanged if it is buggy and the manufacturer cares enough to fix it. With built-in firmware storage, you still have the same proprietary code running behind the scenes. It can have the same bugs, and to fix it, you'll have to use a special flasher, which will probably be proprietary and Windows or DOS only. If it's upgradeable at all.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:34 UTC (Tue) by jebba (guest, #4439) [Link] (5 responses)

> ...the anti-firmware argument...

It's not anti-firmware. It's anti-unfree software. There is free software firmware. Your kernel doesn't have to be non-free. Why should the firmware have to be non-free? This file details the licenses of the firmware shipped with the linux kernel:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-...

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:41 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

in my opinion, if you were really anti-unfree software you would be more opposed to firmware that's not loaded from the OS because it's harder to change.

instead you consider such firmware acceptable and claim that you would be happy if all devices worked that way.

to the extent that your fussing has an effect it's as likely to drive vendors to make the firmware more fixed as it is to get them to open the source. and I defiantly consider the move from a firmware blob loaded by the OS to a firmware blob that requires more effort to change a step in the wrong direction.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 21:19 UTC (Tue) by jebba (guest, #4439) [Link]

> instead you consider such firmware acceptable and claim that you would be happy if all devices worked that way.

I did? When/where?

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:46 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (2 responses)

I agree that open source firmware is even better - hackable hardware is fun and has many of the same advantages as free software. But why is it okay to have non-free firmware on a flash chip where you never see it, but not okay to load the same firmware at runtime?

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 20:52 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

or firmware on a flash chip that requires a windows-only program to update it.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 21:52 UTC (Tue) by nix (subscriber, #2304) [Link]

... and if the update goes wrong you are terminally buggered, as opposed
to load-every-time firmware, where you're not buggered at all.

Firmware vs. loadable/flashable "firm"ware

Posted Sep 17, 2009 12:27 UTC (Thu) by anton (subscriber, #25547) [Link] (2 responses)

Unchangeable firmware is unlikely to have the same bugs as loadable "firm"ware, because the manufacturer cannot afford to replace the hardware in order to fix a critical bug. So they will be more careful during development and testing to ensure that no critical bugs are in the firmware (and catch a lot of other bugs along the way), just like they are for hardware, whereas loadable "firm"ware costs as much to replace as software and will therefore be developed to the standards of proprietary software.

Another way to look at it is that free "firm"ware gives the user the same options as the manufacturer of the software. The same is true for unchangeable firmware (each party can decide to (offer to) replace the hardware at their own cost). But with proprietary loadable firmware the manufacturer gets options to change the firmware that the user doesn't have.

And even if I restrict my view to short-term convenience, unchangeable firmware that just works (as has always been the case in my experience) is certainly more convenient than having to download and possibly even flash new "firm"ware. The worst experience I had with firmware and "firm"ware was with the bcm43xx and b43 "firm"ware where I had to manually download some Windows driver and extract the "firm"ware, twice.

Firmware vs. loadable/flashable "firm"ware

Posted Sep 17, 2009 14:14 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

There's several notable examples to the contrary - look at the problems with the Seagate 1TB drives, for example. The situation with difficult to upgrade firmware is different in that people are more likely to attempt to put workarounds in the driver to deal with the issues, whereas a loadable firmware update can be pushed out as easily as a driver update (and, often, the two will go hand-in-hand).

Broadcom is something of an edge case in terms of their wireless firmware. There's plenty of loadable firmware distributed in the linux-firmware tree and installed by default with most distributions, so in the vast majority of cases the user will see no difference whatsoever.

Firmware vs. loadable/flashable "firm"ware

Posted Sep 17, 2009 14:39 UTC (Thu) by foom (subscriber, #14868) [Link]

> But with proprietary loadable firmware the manufacturer gets options to change the firmware that the user doesn't have.

You talk as if you think unchangeable firmware and non-persistent loadable firmware are the only two options.

But you forgot the option that actually gets used most often as an alternative to non-persistent loadable firmware: flash memory. As the parent comment noted: "you'll have to use a special flasher, which will probably be proprietary and Windows or DOS only"

But if you consider system security, persistent user-modifiable firmware starts looking like a really bad idea. E.g. the recent hack where someone modified the firmware in their Apple Keyboard to add a keylogger. So what will the likely result of that be? I'm willing to bet that fairly soon, all hardware with flash firmware will do signature checks on all firmware uploads.

Realistically, the only techically acceptable options are:

1) Persistent flash firmware, with a signature check on upload to ensure non-malicious firmware. That is: not user modifiable, at all, source code available or not.
2) Non-persistent loadable firmware.

At least with 2, it's possible for a user to modify and load unauthorized firmware into the device, even if the source isn't provided. I know I'd prefer that...