On Sun, Oct 07, 2007 at 09:07:33PM -0500, David Young wrote:
> You are mistaken when you put WiFi firmware in the same category as ROM
> chips, microcode, and ASICs.

>From the QA many vendors put into the images -- yes. From the technical
perspective -- no.

> Firmwares ordinarily add complexity to a microcontroller-based WiFi
> that is way out of proportion to what is necessary to use the chip.
> Bugs accompany that complexity, but documentation does not.

It depends. I can understand some of the reasons to put things in the
firmware, the biggest being that it avoids the driver having to deal
with environment specific issues that are very specific to individual
versions of a device. Given all the interactions necessary for good
radio operations, doing everything in software seems like a bad idea.

> > How do you know that a vendor doesn't have the same backdoors you seem
> > to fear so much in the ASIC?
> 
> We do not know, but I think that it is prudent to regard an opaque
> WiFi firmware that is operating with a 3rd-party device driver as less
> trustworthy than either a ROM implementing industry standards or an ASIC.

Fact is, that pure ROM is dying out at least in the consumer sector. If
possible, it gets replaced with loadable firmware images to save money.
Otherwise EEPROM is used. Looking at all the issues for example in ACPI
land that are still resolved by "Update your BIOS", I don't buy the
argument about a ROM implementing industry standards is more
trustworthy. While it is certainly a drive for higher quality it is also
not unlikely to just document the bugs in the ROM image or the ASIC and
expect driver authors to deal with that. The workaround lists in certain
network drivers like bge(4) speak for that or just consider all the
ASICs that *still* don't get all cases of IP checksumming correct. With
firmware images there is at least some change to see that fixed.

About the specific hardware in question -- I don't think there's any
recent WiFi hardware that doesn't have either an EEPROM chip or requires
a load of microcode or a firmware image. Of the three obvious contenders
in this area, Intel has the firmware, Atheros the blob image and Ralink
the microcode. Intel has done a lot of stupid and bad things with the
firmware like constantly changing interfaces. Sure, they should die for
that. They should learn that a Linux driver is no replacement for QA.
But I still maintain that arguing "because it uses a firmware image" is
wrong. I bet that almost noone beside those involved in the driver would
have known about the "issue", if Intel would allow redistribution. Would
you know that Ralink devices require microcode without looking at the
man page or inside /libdata?

Joerg