[cnst]

This is one good reason why the GNU crowd is doing more harm than good by labelling both the firmware as well as device drivers as "blobs" without taking any time to elaborate that one is much worse than the other.

This is why the terminology used by the BSD community is much more realistic and pragmatic.

http://www.gnu.org/distros/common-distros.html#BSD — «In BSD parlance, the term “blob” means something else: a nonfree driver.»

http://www.openbsd.org/lyrics.html#39 — «Blobs are vendor-compiled binary drivers without any source code.»

http://web.archive.org/web/20060603230017/http://kerneltrap.... — «Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;)» (NB: Theo's talking about the wi(4) firmware, see http://mdoc.su/-/wi.4 .)

[OrgNet]

> the firmware as well as device drivers as "blobs"

I'm pretty sure that both of them could completely compromise you

[cnst]

Did you just miss the original comment?

> USB, i2c and SPI are effective measures against malicious hardware taking control of the system bus and sucking data from peripherals.

BTW, it's not I2C, but I2S that PinePhone has as one of these interfaces, but that makes little difference — it's still hardly something over which you can DMA. (I'd be more concerned about USB, however.)

---

The problem with GNU and Stallman's logic is how arbitrary the line is drawn — if the hardware has proprietary logic like a microwave, that's fine; but if it allows to be upgraded by the user, it's suddenly not fine. The difference between one of these devices having some ROM, or letting the host upload the firmware, is minuscule. In fact, if you're concerned about hardware compromise, it would actually be better if the hardware is ROM-less, and you're the one who is uploading that binary blob into a device, because then they can't just intercept your laptop on being shipped from the vendor by simply installing a compromised memory chip with compromised firmware. (Of course, this is rather trivial example, because if they do intercept hardware, then they might as well just swap the whole device even if it's ROM-less, but then they gotta fit more stuff into a smaller space. And, of course, the whole thing being OSS is the best option, but this is just a threat-model analysis here — it's slightly more secure to upload the firmware yourself than have it ship with the hardware.)

[icebraining]

> In fact, if you're concerned about hardware compromise

Right, but hardware compromised has never been the focus of GNU and Stallman. Saying the distinction is arbitrary from that POV is rather missing the point.

[cnst]

The distinction is still arbitrary even if you omit the hardware compromise aspect.

I mean, let's go back to that quote about assembler from Theo:

http://web.archive.org/web/20060603230017/http://kerneltrap.... — «Of course, also note that we don't want to become Hermes (the architecture of the Lucent/Prism/Symbol chip) assembly language programmers... we have more than enough to do. Just a specific example. Please, people, don't load us up with more tasks ;)» (NB: Theo's talking about the wi(4) firmware, see http://mdoc.su/-/wi.4 .)

DDG for "Stallman microwave" returns this page and this quote:

http://stallman.org/stallman-computing.html — «As for microwave ovens and other appliances, if updating software is not a normal part of use of the device, then it is not a computer.»

Now, what does that firmware for wi(4) actually even does? How's it different from the hardware itself? What sort of language is it written in? I'm mean, I'm a kernel developer here, I've hacked drivers and subsystems because they weren't working properly, but are you seriously going to argue here that actually updating this firmware is any more common than updating the software of the microwave?

I mean, let's take a look and find out. NetBSD appears to have it all in a single dir over at http://bxr.su/n/sys/dev/microcode/wi/ — clicking on any individual file, then the CVSweb link, reveals that it's been committed 15 to 17 years ago and not once updated (apart from the whitespace in the .h header file). Searching for these files in OpenBSD reveals the same situation — http://bxr.su/o/sys/dev/microcode/symbol/ .

So, basically, the manufacturer decided to save a few cents by omitting a ROM component on their cards; requiring you to bootstrap the device by giving it its firmware on each boot. How's that any different from the situation where the ROM chip is fixed from the factory? As a user and kernel developer, I don't really see a difference. Would it be nice if the firmware is OSS? I mean, sure, but it's written in a proprietary language anyways, for proprietary hardware, and it's really much more part of the hardware than it is of the software or the OS, and there's better battles to fight here than getting this sort of useless thing FLOSS'ed.

In fact, those 12-hour clocks on most microwaves are really annoying, and there's never an option to fix it. It should be possible to get the source code for all those microwaves to fix them to use 24-h time; I'd much rather campaign for that than for making wi(4)'s firmware OSS.

[zzo38computer]

If it is compromised then they can install ROM and use that instead of the uploaded firmware (possibly using a checksum to make it more difficult to detect).