Re: [free-software-melb] Agitating for free firmware (was: Chipping in for an Ouya console?)

On Sun, Aug 26, 2012 at 10:04:05AM +1000, Ben Finney wrote:

Adam Bolte writes:

...

On Sat, Aug 25, 2012 at 04:32:36PM +1000, Ben Sturmfels wrote:

...

Choosing an AMD card means I'm giving some profits to AMD, who offer dramatically better support for free software. On the other hand though, I'd be required to use proprietary firmware.

True. Even basic embedded proprietary firmware that users are not expected to interact with directly can still be a problem, as most people who have purchased a SSD recently would be able to tell you. […]

...

If my above assumptions are correct, why treat graphics driver firmware specially?

First you'd need to show that we're treating graphics firmware specially. I think the same criticisms are applied to vendors who act against freedom in network interface firmware, graphics firmware, radio firmware, etc.

Like yourself, instead of purchasing computer hardware from perhaps a local computer retailer, Ben has elected to import hardware from the US on the basis that these Think Penguin machines are tested to be "compatible" with free software - or at least that was my understanding. However, even those machines provide the option of various SSDs, HDD&SSD hybrids (all surely requiring non-free firmware), and even non-free BIOSs. eg. https://www.thinkpenguin.com/gnu-linux/emperor-penguin-gnu-linux-notebook Yet, these issues are rarely given any attention. Instead, most efforts seem to be directed towards network and graphics firmware. Observe that all Think Penguin desktops and laptops use Intel graphics cards by default - presumably largely to avoid the issue of proprietary firmware. So yes I think HDD, SSD firmware and even BIOS software is being treated quite differently to graphics firmware in general by free software advocates - even though those IMO represent more serious threats (discussed below). I suspect this is largely because the FSF made a big deal about the binary blobs in the Linux kernel - something that everybody uses and was actually being distributed so was a much easier win (even if far less important).

...

I'm certainly not saying it's wrong to demand free firmware, however I'm curious why some firmware is treated differently. Is it because one lives in your filesystem on your HDD, but the other is stored in an EEPROM (and if so, why does this matter)?

Almost. The important matter is: who has effective freedom in the device once it's in the hands of the customer, to determine what it does and modify its behaviour and share those modifications with others?

With some devices, such as the keyboard controller chip, the answer is something close to “no-one”. These are devices whose behaviour is entirely determined at the time the customer buys them, and are not under the influence of anyone to change that behaviour.

More specifically, a keyboard controller chip's behaviour would be determined at the time of manufacture and would likely not be reprogrammable by said manufacturer even if the device were returned. It makes sense that having access to such code wouldn't be beneficial.

Such devices are effectively unchanging machines, and don't present much of an imbalance of freedom between the vendor and customer: neither is in a privileged position.

With other devices, such as the CPU, the answer is close to “the customer”. The whole point of the CPU is to be endlessly reprogrammable, and the customer has close to infinite freedom to determine that programming.

Yep - it would be good if that were always true. Which is why I (unlike Think Penguin) try to avoid Intel products. http://www.engadget.com/2010/09/18/intel-wants-to-charge-50-to-unlock-stuff-... (as if that wasn't bad enough, it requires running a proprietary Windows program to unlock) You might also recall the Pentium III unique ID controversy of 1999? Intel later released a program to disable this functionality, suggesting Intel has had for a long time more control over the CPUs it manufacturers than a user would have once the chips leave the factory. http://www.wired.com/politics/law/news/2000/04/35950 For the most part however, Intel doesn't issue microcode updates. AMD has only enabled users to update microcode since 2009 (on GNU/Linux systems at least). Out of sight, out of mind? (See the discussion of HDD firmware below for another example of firmware that is upgradable but until recently rarely was.)

Such devices are effectively under the control of the customer, not the vendor. So those aren't much of a problem for the customer's freedom either.

The border that is contentious is where we find devices designed to have their behaviour modified, but in a rather limited way and through tightly restricted channels – such as upgrading the firmware at boot time or run time from a binary blob.

But do these graphic card firmwares really see proprietary updates from vendors that modify the behaviour in some useful way? Or is this something you are assuming just because a firmware needs to be loaded at boot, and proprietary graphics card drivers (which include the firmware) regularly get updates? I just did a quick check, and downloaded the Debian firmware-nonfree_0.28+squeeze1.tar.gz tarball, and generated an MD5SUM checksum list of everything in linux-nonfree/radeon/*.bin. I then compared that to what was in the Wheezy firmware-linux-nonfree 0.36 source package, and all checksums matched. It seems to me that the problem you are describing isn't real for radeon products throughout the last year - if ever.

For these difficult-to-update devices, the question then turns on who has effective freedom to deploy updates to the device's behaviour. If the customer is effectively restricted from deploying their choice of update, while the vendor has a privileged channel to get updates to the device, then that's a problem for the customer's freedom.

Has anyone developing the radeon drivers ever complained that the non-free firmware (despite having hardware specifications from AMD) was restricted in getting the card to function as desired in any meaningful way? Or is this also an assumption? Could it possibly be that the firmware simply has to exist, but cannot be modified to any obvious benefit were access to the code provided (assuming the firmware is functioning correctly)?

If the customer has no less freedom than the vendor to deploy their choice of update to the device's behaviour, then there's no disparity between the vendor's freedom in that device and the customer's.

This is why a keyboard chip which no-one can modify isn't a significant problem for freedom, and the CPU which the customer can easily modify isn't a significant problem for freedom, while a graphics chip commonly is a problem and we pay close attention to which vendors act to preserve or restrict the customer's freedom in the device.

Citation that the non-free firmware is actually restricting the free software developers from making the card function in any desirable way which the hardware is capable of would be useful. Whilst I haven't performed much investigation here myself, it's difficult to do so with the Xorg wiki always being down as of late. I certainly haven't heard or seen any such claims.

The border is ever shifting, too. Whereas persistent storage devices (such as HDDs) used to have behaviour that neither the vendor nor the customer could update, many SSDs now have the expectation of updates to their behaviour – and the vendor has the same kind of privileged path to choose those updates which the customer doesn't have.

My impression is that the firmware found in graphics cards is far more trivial than that found in devices such as SSDs. Looking again at the Wheezy radeon firmware files, the largest is CAYMAN_mc.bin at 24K. Compare that to my current SSD firmware at 442K. See for yourself - http://kb.sandisk.com/app/answers/detail/a_id/10476/related/1 "SanDisk Extreme 480GB SSD", extract the ramdisk.gz image and see the firmware.bin file (along with separate proprietary(?) updater files). If we take a trip down memory lane... recall the IBM Death^H^H^H^H^HDeskStar failures from 2001? From wikipedia: "A firmware update gives a clue to some of the issues: * Possible data corruption due to a problem with S.M.A.R.T. background operations. * Application of wear levelling to avoid the heads dwelling too long over the same area" https://en.wikipedia.org/wiki/Deskstar There seemingly were issues with the drives beyond firmware, however my point is that it has been clear that proprietary HDD firmwares have been: A. Upgradable by users and manufacturers for well over a decade now (even if updates haven't commonly been released publicly by manufacturers in all that time). B. There are legitimate reasons why end users are being hurt by proprietary firmwares in devices such as HDDs. C. Such issues have been well known for a long time, but few people actually care.

So vigilance is required: the tendency is for newer devices to place freedom to choose the device's behaviour in the vendor's hands while denying it to the customer.

On the contrary, I'm not convinced that any of these firmware blobs are necessarily a new thing. Video cards have always required firmware or otherwise a graphics BIOS (be it on EEPROM or loaded at runtime) which is almost always proprietary, and has been re-flashable easily for many years where stored on EEPROM. HDDs and SSDs have also always used proprietary firmware, however perhaps the firmware hasn't been easy to upgrade past a decade or so ago? Computer BIOSs also have seen very little progress in becoming free (or having free replacements readily available) despite being a significant attack on freedom and a PITA in general, however AMD appears to be helping to change that with their pledged Coreboot support for new processors. http://www.hardware.slashdot.org/story/11/05/09/1115235/AMD-To-Support-Coreb... I believe computer BIOS updates are quite significant in size - far greater than up to a 24K binary for a graphics card. I've mentioned at prior meet-ups the issue with my laptop not allowing me to display to an external HDMI/VGA connector by default (when an LCD is detected) - a feature many BIOSs offer and I would find very useful. By contrast, I am not able to think of a single benefit to modifying the graphics card firmware - aside from hypothetical scenarios where said firmware were to be malfunctioning or was not optimal. To care about graphics card firmware and not the BIOS when making purchasing decisions seems a bit hypocritical IMO. Lastly, we've always had proprietary firmware for our main internal storage devices, and this too has always been ignored. It's just that now such devices (and thus the firmware that drives them) have become more complex and hence more commonly problematic, more upgradable and the threat even more obvious. -Adam