8 ms·

The FSF is papering over a binary blob

60 points by blasdel 15y ago

smoyer 15y ago
Isn't all my other non-free software just blobs that are loaded by my free software? Why isn't it my right as a user to choose the closed software? If hiding the blob from the user makes it okay, why not apply that thinking to drivers wrapped by the NDISwrapper?
- zdw 15y ago
  The problem is that binary-only drivers are in privileged locations and frequently cause OS kernel problems. As they're binary only, they've basically undebuggable, and frequently nonportable to other systems. OpenBSD is very strong on this, and often has drivers that are blob-free when other OS's don't: http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html This isn't restricted only to free OS's either - nearly 30% of Vista crashes were attributed to buggy nVidia drivers: http://arstechnica.com/hardware/news/2008/03/vista-capable-lawsuit-paints-picture-of-buggy-nvidia-drivers.ars http://arstechnica.com/hardware/news/2008/03/vista-capable-l... In short, if you want a system you can at least have a chance at fixing when it breaks, you need the source code to your drivers. This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver, but can be a hassle if there are restrictions on distribution of the firmware.
  - Someone 15y ago
    "This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver" In most scenarios where I think a '3rd party chip with its own firmware' makes sense, that chip can generate interrupts and/or do DMA. Both cases will (typically) allow that firmware to crash the OS on the other CPU (or bring it to its knees by DDOS-ing it with interrupts) Because of that, I do not see why a blob running on that 3rd party chip would be less of an issue than a blob running on the main CPU.
    - tedunangst 15y ago
      Why is a blob running on a 3rd party chip less of an issue than hard coded transistors on a 3rd party chip?
      - Someone 15y ago
        Good argument. I would say it is not less of an issue, but I also think it isn't less of an issue than having a blob running on the main CPU. IMO, such blobs only become problematic if they do not work properly or aren't flexible enough. Whether they are made in soft-, firm-, or hardware is immaterial for that. In the end, for almost every case (yes, you probably _can_ build your own 1kW 6502-class CPU from sand, if you are good, start young and persevere for a couple of decennia) it boils down to the fact that you will have to trust some other people. After all, you cannot reasonably verify that say a x64 CPU really behaves as its documentation states it does.
        tedunangst 15y ago
        One reason the blob on the CPU is so different is the way it interfaces with your code. In that regard, it is almost never flexible enough and the exposed interface surface is generally enormous. Your kernel version is supported only at the mercy of nvidia or whoever. Firmware chunks have a very simple interface: load. Anybody with the firmware file and some basic documentation can make it happen.
  - mseebach 15y ago
    > This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver I'd argue that it's an entirely different kettle of fish. Once the firmware blob is loaded into the chip, the hardware widget works exactly like it would otherwise. If the firmware just lived on a ROM inside the widget, you'd never know it existed. Protesting closed source drivers I'm all behind for the reasons you mention, but closed source firmware just simply can't aggravate me.
- icebraining 15y ago
  Why isn't it my right as a user to choose the closed software? It's your right as the user - there's nothing to stop you from doing that. They simply won't help you with it, and any distro that does is deemed non-really-free (like Debian). Don't confuse "right to do" with "right to being easy to do".
av500 15y ago
So Richard Stallman would be OK to use a PC with a closed source BIOS as long as there is no way to update it?
- matthavener 15y ago
  I doubt it. RMS uses some laptop specifically because the processor is open source. From his wiki page: "Stallman's only computer is a Lemote Yeeloong netbook (using the same company's Loongson processor) which he chose because it can run with 100% free software even at the BIOS level, stating "freedom is my priority. I've campaigned for freedom since 1983, and I am not going to surrender that freedom for the sake of a more convenient computer."[57] Lemote is a joint venture of the Institute of Computing Technology of the Chinese Academy of Sciences, an institution of the State Council of China."
  - shahidhussain 15y ago
    More details on that laptop, if it piques your interest: http://www.amazon.com/Screen-Lemote-Yeeloong-8101_B-Netbook/dp/B005XH10NQ http://www.amazon.com/Screen-Lemote-Yeeloong-8101_B-Netbook/...
    - apgwoz 15y ago
      It'd be much more compelling if I knew how much RAM I could jam in the thing. Comes with 1GB, but if I could get 4 in there, it'd be a rocking little machine.
    - deleted 15y ago
      [deleted]
    - wazoox 15y ago
      Not too bad a configuration, except for the limited screen.
  - tobylane 15y ago
    China? Could he not side with someone who dislikes USA more? Surely there's a North Korean laptop that fits his requirements. Not that anyone other than Stallman is right, it's just odd.
_delirium 15y ago
It's an interesting edge case when you have someone actually moving from one model to another. But I think even OpenBSD's famously strong policy on binary blobs would allow this one, at least as they've implemented the policy in the past. They require source for drivers, which means anything you need to load onto the chip or use to communicate with it, but not for every piece of ROM that's internal to a chip. For example, Intel and AMD both microcode some instructions in firmware on their chips, rather than implementing them in silicon, and OpenBSD is ok with that, treating the silicon and microcoded part as all part of the blackbox chip package, rather than as a "driver" that requires source.
- tedunangst 15y ago
  Actually, the requirement for adding firmware (something that is loaded onto a chip) to OpenBSD is that it be modifiable. Source isn't required. (Speaking only about firmware that goes on the chip, not HAL layers that run on the CPU. Those are banned in binary form.) I'd say the biggest difference here is that OpenBSD's goal is to make a free operating system, not a free phone.
jrockway 15y ago
To be fair, I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware. So even if we had full source code to the radio's firmware, it would be illegal to sell a device that could be user-programmed. Or something. (I don't know how widely enforced this is, though. I've never had any trouble telling my wifi equipment I'm outside of the US to get access to extra channels. I guess this is a federal crime, but good luck enforcing it.)
- MostAwesomeDude 15y ago
  This argument used to be used all the time by WiFi device manufacturers, and it turns out to be bullshit. The truth is that you, the operator of the device, assume all liability for your modifications, but there is no reason you can't flash/modify your firmware to, say, improve your power-saving abilities or improve your scanning times. We have enough source code for Atheros devices to be able to reprogram them as we see fit, and the FCC doesn't really care.
  - jrockway 15y ago
    Glad to be proven wrong.
- ChuckMcM 15y ago
  Demonstrably untrue since you can download the Gnu-radio [1] kit which is supported by a module sold by Ettus [2] which basically allows you to create arbitrary software radios. If you ever wanted to build a hyper-encrypted-fast-flip-wideband-frequency-hopping super sekrit access point, these guys have what you need :-). Of course you would end up needing two of them at least. [1] http://gnuradio.org/redmine/projects/gnuradio/wiki http://gnuradio.org/redmine/projects/gnuradio/wiki [2] http://www.ettus.com/products http://www.ettus.com/products
- derleth 15y ago
  > I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware. If this were the case, you (the private individual) would not be allowed to have anything that would allow you to build a radio transmitter of any form. Also, look at GNU Radio: http://gnuradio.org/redmine/projects/gnuradio http://gnuradio.org/redmine/projects/gnuradio
zokier 15y ago
I wonder how hard it is to swap peripheral chips in embedded solutions like this? And more importantly, are there any WLAN chips with good blobless drivers? Somehow it seems that they always have been a pita for Linux
sliverstorm 15y ago
This solution seems rather less "free" to me. I can't update the firmware? Because it makes you feel dirty to allow me to?
- jws 15y ago
  Yes. And when a malicious packet is discovered that compromises the RTOS on the chip, and the vendor patches it, this cost raising ideological kludge will leave you devices vulnerable forever. (I say this, knowing full well that I suffer from the closed nature of this device. The DreamPlug uses this, and the access point version of the firmware only supports 8 devices. That doesn't go very far with the usual complement of mobile devices people carry. I am powerless to patch it and will have to add a dedicated access point to work around it, but paying to freeze this particular deficient version of code is ridiculous.)
derleth 15y ago
What if, instead of moving the software to a binary blob, they went a bit nuts and moved it to an ASIC that did the same job in random logic? That is, what if they re-implemented the software in pure hardware?
- sliverstorm 15y ago
  Are you suggesting they reimplement the Marvell WLAN chip themselves? "Hey guys, I know, let's add an analog ASIC! It can't be that hard!"
  - derleth 15y ago
    Don't be so literal. I'm saying hardware and software are more interchangeable than people realize.

60 points by blasdel 15y ago

Isn't all my other non-free software just blobs that are loaded by my free software? Why isn't it my right as a user to choose the closed software? If hiding the blob from the user makes it okay, why not apply that thinking to drivers wrapped by the NDISwrapper?

zdw 15y ago
The problem is that binary-only drivers are in privileged locations and frequently cause OS kernel problems. As they're binary only, they've basically undebuggable, and frequently nonportable to other systems. OpenBSD is very strong on this, and often has drivers that are blob-free when other OS's don't: http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html http://onlamp.com/bsd/2006/04/27/openbsd-3_9.html This isn't restricted only to free OS's either - nearly 30% of Vista crashes were attributed to buggy nVidia drivers: http://arstechnica.com/hardware/news/2008/03/vista-capable-lawsuit-paints-picture-of-buggy-nvidia-drivers.ars http://arstechnica.com/hardware/news/2008/03/vista-capable-l... In short, if you want a system you can at least have a chance at fixing when it breaks, you need the source code to your drivers. This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver, but can be a hassle if there are restrictions on distribution of the firmware.
- Someone 15y ago
  "This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver" In most scenarios where I think a '3rd party chip with its own firmware' makes sense, that chip can generate interrupts and/or do DMA. Both cases will (typically) allow that firmware to crash the OS on the other CPU (or bring it to its knees by DDOS-ing it with interrupts) Because of that, I do not see why a blob running on that 3rd party chip would be less of an issue than a blob running on the main CPU.
  - tedunangst 15y ago
    Why is a blob running on a 3rd party chip less of an issue than hard coded transistors on a 3rd party chip?
    - Someone 15y ago
      Good argument. I would say it is not less of an issue, but I also think it isn't less of an issue than having a blob running on the main CPU. IMO, such blobs only become problematic if they do not work properly or aren't flexible enough. Whether they are made in soft-, firm-, or hardware is immaterial for that. In the end, for almost every case (yes, you probably _can_ build your own 1kW 6502-class CPU from sand, if you are good, start young and persevere for a couple of decennia) it boils down to the fact that you will have to trust some other people. After all, you cannot reasonably verify that say a x64 CPU really behaves as its documentation states it does.
      - tedunangst 15y ago
        One reason the blob on the CPU is so different is the way it interfaces with your code. In that regard, it is almost never flexible enough and the exposed interface surface is generally enormous. Your kernel version is supported only at the mercy of nvidia or whoever. Firmware chunks have a very simple interface: load. Anybody with the firmware file and some basic documentation can make it happen.
- mseebach 15y ago
  > This case in particular is a firmware load into a 3rd party chip, which isn't usually as bad a a binary driver I'd argue that it's an entirely different kettle of fish. Once the firmware blob is loaded into the chip, the hardware widget works exactly like it would otherwise. If the firmware just lived on a ROM inside the widget, you'd never know it existed. Protesting closed source drivers I'm all behind for the reasons you mention, but closed source firmware just simply can't aggravate me.
icebraining 15y ago
Why isn't it my right as a user to choose the closed software? It's your right as the user - there's nothing to stop you from doing that. They simply won't help you with it, and any distro that does is deemed non-really-free (like Debian). Don't confuse "right to do" with "right to being easy to do".

av500 15y ago

So Richard Stallman would be OK to use a PC with a closed source BIOS as long as there is no way to update it?

matthavener 15y ago
I doubt it. RMS uses some laptop specifically because the processor is open source. From his wiki page: "Stallman's only computer is a Lemote Yeeloong netbook (using the same company's Loongson processor) which he chose because it can run with 100% free software even at the BIOS level, stating "freedom is my priority. I've campaigned for freedom since 1983, and I am not going to surrender that freedom for the sake of a more convenient computer."[57] Lemote is a joint venture of the Institute of Computing Technology of the Chinese Academy of Sciences, an institution of the State Council of China."
- shahidhussain 15y ago
  More details on that laptop, if it piques your interest: http://www.amazon.com/Screen-Lemote-Yeeloong-8101_B-Netbook/dp/B005XH10NQ http://www.amazon.com/Screen-Lemote-Yeeloong-8101_B-Netbook/...
  - apgwoz 15y ago
    It'd be much more compelling if I knew how much RAM I could jam in the thing. Comes with 1GB, but if I could get 4 in there, it'd be a rocking little machine.
  - deleted 15y ago
    [deleted]
  - wazoox 15y ago
    Not too bad a configuration, except for the limited screen.
- tobylane 15y ago
  China? Could he not side with someone who dislikes USA more? Surely there's a North Korean laptop that fits his requirements. Not that anyone other than Stallman is right, it's just odd.

_delirium 15y ago

It's an interesting edge case when you have someone actually moving from one model to another. But I think even OpenBSD's famously strong policy on binary blobs would allow this one, at least as they've implemented the policy in the past. They require source for drivers, which means anything you need to load onto the chip or use to communicate with it, but not for every piece of ROM that's internal to a chip. For example, Intel and AMD both microcode some instructions in firmware on their chips, rather than implementing them in silicon, and OpenBSD is ok with that, treating the silicon and microcoded part as all part of the blackbox chip package, rather than as a "driver" that requires source.

tedunangst 15y ago
Actually, the requirement for adding firmware (something that is loaded onto a chip) to OpenBSD is that it be modifiable. Source isn't required. (Speaking only about firmware that goes on the chip, not HAL layers that run on the CPU. Those are banned in binary form.) I'd say the biggest difference here is that OpenBSD's goal is to make a free operating system, not a free phone.

jrockway 15y ago

To be fair, I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware. So even if we had full source code to the radio's firmware, it would be illegal to sell a device that could be user-programmed. Or something. (I don't know how widely enforced this is, though. I've never had any trouble telling my wifi equipment I'm outside of the US to get access to extra channels. I guess this is a federal crime, but good luck enforcing it.)

MostAwesomeDude 15y ago
This argument used to be used all the time by WiFi device manufacturers, and it turns out to be bullshit. The truth is that you, the operator of the device, assume all liability for your modifications, but there is no reason you can't flash/modify your firmware to, say, improve your power-saving abilities or improve your scanning times. We have enough source code for Atheros devices to be able to reprogram them as we see fit, and the FCC doesn't really care.
- jrockway 15y ago
  Glad to be proven wrong.
ChuckMcM 15y ago
Demonstrably untrue since you can download the Gnu-radio [1] kit which is supported by a module sold by Ettus [2] which basically allows you to create arbitrary software radios. If you ever wanted to build a hyper-encrypted-fast-flip-wideband-frequency-hopping super sekrit access point, these guys have what you need :-). Of course you would end up needing two of them at least. [1] http://gnuradio.org/redmine/projects/gnuradio/wiki http://gnuradio.org/redmine/projects/gnuradio/wiki [2] http://www.ettus.com/products http://www.ettus.com/products
derleth 15y ago
> I'm pretty sure the FCC would not allow you to sell a device in the US that lets you modify the RF firmware. If this were the case, you (the private individual) would not be allowed to have anything that would allow you to build a radio transmitter of any form. Also, look at GNU Radio: http://gnuradio.org/redmine/projects/gnuradio http://gnuradio.org/redmine/projects/gnuradio

zokier 15y ago

I wonder how hard it is to swap peripheral chips in embedded solutions like this? And more importantly, are there any WLAN chips with good blobless drivers? Somehow it seems that they always have been a pita for Linux

sliverstorm 15y ago

This solution seems rather less "free" to me. I can't update the firmware? Because it makes you feel dirty to allow me to?

jws 15y ago
Yes. And when a malicious packet is discovered that compromises the RTOS on the chip, and the vendor patches it, this cost raising ideological kludge will leave you devices vulnerable forever. (I say this, knowing full well that I suffer from the closed nature of this device. The DreamPlug uses this, and the access point version of the firmware only supports 8 devices. That doesn't go very far with the usual complement of mobile devices people carry. I am powerless to patch it and will have to add a dedicated access point to work around it, but paying to freeze this particular deficient version of code is ridiculous.)

derleth 15y ago

What if, instead of moving the software to a binary blob, they went a bit nuts and moved it to an ASIC that did the same job in random logic? That is, what if they re-implemented the software in pure hardware?

sliverstorm 15y ago
Are you suggesting they reimplement the Marvell WLAN chip themselves? "Hey guys, I know, let's add an analog ASIC! It can't be that hard!"
- derleth 15y ago
  Don't be so literal. I'm saying hardware and software are more interchangeable than people realize.