On Sun, Aug 26, 2012 at 10:04:05AM +1000, Ben Finney wrote:
> Adam Bolte <abo...@systemsaviour.com>
> 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.

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.

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

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

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
* Application of wear levelling to avoid the heads dwelling too long over
the same area"


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

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

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


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.


Attachment: signature.asc
Description: Digital signature

Free-software-melb mailing list

Reply via email to