FSF updates its "fully free" distribution list

Posted Sep 14, 2009 17:59 UTC (Mon) by mdomsch (guest, #5920)
Parent article: FSF updates its "fully free" distribution list

If the difference between "fully free" and "completely nonfunctional on virtually any hardware", I'll forego the "fully free" moniker gladly. CPU microcode and NIC firmware are necessities, at least on the CPUs and NICs available on the market.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 14:06 UTC (Tue) by jebba (guest, #4439) [Link] (14 responses)

This is simply false. The only NIC, last time I checked, in the kernel that uploaded firmware is TG3 and it is only needed for some features--it can be used without the firmware. There was an Intel NIC too that used firmware, but there was a second driver in the kernel that didn't require it (eepro100 v e100 iirc).

The only big category of hardware that most users encounter that need firmware is wifi drivers. Other than that, there is really very little hardware in use on most systems that needs firmware uploaded to it by the kernel.

-Jeff

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 14:31 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (13 responses)

bnx2 requires firmware. tg3 requires it on certain chips, as does e100 - eepro100 was removed from the kernel. You're not terribly likely to be hit, but it is a risk.

There's more of a problem with graphics. You won't get accelerated 2D, let alone 3D on radeon without firmware - the same's true for nouveau. Intel's the only option if you prefer your firmware burned-in rather than loaded at runtime.

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 19:23 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (9 responses)

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

FSF updates its "fully free" distribution list

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

OK, please point to the firmware for accelerated 2D on radeon. There's the
AtomBIOS, but that's *on the card* and interpreted by the CPU, thus is no
more 'firmware' than ACPI tables. If by 'firmware' you mean something
which has to be uploaded to the card to do accelerated 2D, I can't find it
in a hunt through the xf86-video-ati tree. So, er, where is it?

FSF updates its "fully free" distribution list

Posted Sep 15, 2009 22:10 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (1 responses)

It's in the DRM layer - accelerated 2D on r300 and later uses the command processor on the card, which requires DRM and therefore the firmware.

FSF updates its "fully free" distribution list

Posted Sep 16, 2009 0:03 UTC (Wed) by nix (subscriber, #2304) [Link]

Ah, right, I didn't look at that. I guess that means my r770 here is
entirely unaccelerated, as it doesn't have a DRM layer yet. I had no idea:
it does everything I ask of it instantaneously (except for 3D of course).
Even hi-def textured video...

... bloody 'ell this modern kit is nippy.