Linked by Thom Holwerda on Tue 6th Jan 2009 13:48 UTC
Debian and its clones "The developers behind the Debian Linux distribution are preparing for the upcoming release of Debian 5, which is codenamed Lenny. The decision to move forward with the release follows a contentious vote over whether to permit the inclusion of binary blobs in the new version of the distribution. Consensus coalesced around a controversial proposal to "assume blobs comply with the GPL unless proven otherwise."
Thread beginning with comment 342580
To read all comments associated with this story, please click here.
Not really blobs, just BLOBs
by mirabilos on Wed 7th Jan 2009 12:04 UTC
mirabilos
Member since:
2008-03-18

Note that firmware is not a blob in the meaning of
the „Stop Blob“ campaign (the original definition
of BLOB is Binary Large OBject and stems from the
database realm, per which audio, imagery, etc. are
BLOBs too). The criterium not matched is: runs on
the (host system) CPU. Firmware runs directly on
peripheral hardware and has no chance to access
the main system/kernel, and as such, it shall be
considered part of the hardware.

/me still wonders why vendors choose to save these
few eurocents worth of Flash-EPROM where such firm-
ware is ordinarily stored, just to go through all
this hassle…

Reply Score: 2

hyriand Member since:
2006-04-03

/OT: That's to make it easier for manufacturers to provide updated firmware by releasing a new driver version.

Flashing the eprom every time the driver loads or when it's updated is tedious and error prone.

Reply Parent Score: 2

RE: Not really blobs, just BLOBs
by timl on Sat 10th Jan 2009 13:49 in reply to "Not really blobs, just BLOBs"
timl Member since:
2005-12-06

Firmware runs directly on
peripheral hardware and has no chance to access
the main system/kernel, and as such, it shall be
considered part of the hardware.

While I agree that by and large firmware should be considered as part of the hardware, I'm not convinced firmware cannot access the main system. If I understand correctly, Bus Master DMA is a feature of PCI (and newer) buses that allow devices to directly access main memory on their own accord. A buggy or malicious firmware in the device could theoretically overwrite kernel code, and so crash or hack the system. While this may not be a huge concern to the average user, I can understand people with big security concerns viewing this as a problem.

For completeness, I think that IOMMUs in modern systems can mitigate or prevent this kind of problem, just like the MMU gave us memory protection between processes. I'm not entirely sure on this though, nor how well the memory *protection* side of IOMMUs is used in current OSes. Anyone care to comment on that?

/me still wonders why vendors choose to save these
few eurocents worth of Flash-EPROM where such firm-
ware is ordinarily stored, just to go through all
this hassle…


1. For big volumes, those few cents really do add up. And it's not only the cost of the chip itself, but also the bigger circuit board and the time required for programming the chip.

2. A firmware update now just becomes a driver update, which for the average user is handled semi-automatically, instead of a more complicated and risky procedure of flashing a chip. Apart from the merits this has in itself (no customers whining they broke their device because the flashing went wrong), you can also get away with releasing initial firmware early on, and therefore having the device on the market earlier. You just patch up the firmware later, like (unfortunately) has become commonplace with other software as well. Especially in the consumer market, being the first to offer a certain device is a huge plus for a manufacturer!

Reply Parent Score: 1