4 ms·

> We went with Redpine Signal as their chipset does not require a firmware download at runtime like other vendors; having a downloadable firmware would violate

> We went with Redpine Signal as their chipset does not require a firmware download at runtime like other vendors; having a downloadable firmware would violate the Free Software Foundation’s RYF requirements. This really does not resonate with me. In most of these chips there is a functional or partially functional firmware in ROM, then the OS applies a RAM patch to provide full functionality or address functional or security issues. I'm not sure how I would be more free or secure if Broadcom or Intel placed the full firmware in the ROM and never updated it, than if the continued to supply updated firmware blobs. The firmware for these devices historically is riddled with security issues, just recently this CVE affected most of the Intel AC WiFi cards [1] Also Redpine supports firmware blob updates with some versions of their hardware, so I'm not sure if they are just playing word games here by saying it will WORK without extra blobs, but then expect everyone will really still use the blobs to stay up-to-date. [2] [1] https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00128.html https://www.intel.com/content/www/us/en/security-center/advi... [2] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/rsi https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

abrowne 8y ago
I believe the FSF position is that non-updatable firmware can be considered "part of the hardware", while updatable firmware cannot. I think they're concerned that updated firmware could change how the device functions in ways you can't control.
- btashton 8y ago
  Except that I am almost 100% certain [1] that they are using the RS9113 which as I suspected IS updateable (in some cases wirelessly) [2]. In fact in the Linux Firmware tree they have multiple firmware images depending on how you want the device to function. [3] >The host MCU can update the RS9113 module FW over UART using the kermit protocol or over SPI using the proprietary binary protocol. The default UART baud rate is 115200 kbps 8N1 with xon/off or no flow control. For baud rate >900000, hardware flow control must be used. Refer to the WiSeConnect PRM for more info - the "Upgrading the Firmware in Module" section discusses the SPI mode and "Firmware Upgradation" section discusses the UART mode. [1] https://source.puri.sm/bob.ham/image-builder/commit/856c9caf647aca14edfb125fb86b94ddb1240287 https://source.puri.sm/bob.ham/image-builder/commit/856c9caf... [2] http://www.redpinesignals.com/faqs.php http://www.redpinesignals.com/faqs.php [3] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/rsi?id=c1aa76a28c8031f747f6589e9b0f5aca8924a5e7 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...
bubblethink 8y ago
There are a lot of games overall. They made this entire post about how using a blob on a co-processor is fine because FSF guidelines have an exception for that. So after some gymnastics, you can make it look like your main processor needs no blobs. I don't know how they wrote this article with a straight face: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/ https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...
- confounded 8y ago
  What would you propose they do?
  - bubblethink 8y ago
    Live with the blob, and accept that the certification is quite meaningless if you have to do such gymnastics to get it.
    - madez 8y ago
      I disagree. Requiring it puts pressure on the manufacturers to do it better and be more open.
      - snaky 8y ago
        Loading the blob by M4 core instead of A53 core don't put any pressure on the manufacturers.
        madez 8y ago
        Just letting another chip do the loading seems to be only part of the solution. The other part is to load it from read-only memory so it cannot be modified after production. That is what I consider to be the crucial property: the firmware must not be updateable.
        8y ago
seba_dos1 8y ago
I understand why FSF has this "no downloadable firmware" rule (they have to put a line somewhere), and I'm by all means a 100% Free Software zealot, but I honestly believe that this rule simply makes it not worth pursuing FSF certification in a device like a mobile phone, as you're ending up with actually less freedom as a user and no way to verify that it's really worth it (after all, a possibility to upgrade your firmware may simply be undocumented and you have no way to be sure that it's not there).
- sounds 8y ago
  Just speaking as one free software lover to another, I am happier that the Redpine Signal doesn't need downloadable firmware to function. It means that there will be just one version of firmware shipped. Just one version of firmware that the whole community will focus on analyzing, patching (only for the librem phone, it's only pure chance if that helps any other device), and if a patch is needed: * Redpine can either tell the entire community how to flash the firmware, or else the egg is on their face for shipping a broken firmware. * (There's basically no chance that the Redpine chip is actually not field-upgradeable if you have the right vendor tool and probably also a windows box to run the tool on.) The rest of the world seems to think, "flash it every time it boots up and I don't really care where that binary blob came from." I'll also just add, I can respect your position. Thanks for supporting Free Software, and I get it that there's value to being able to upgrade. That's kind of what I'm hoping happens later, if (cough, cough, when) there's a bug or exploit or worse. If purism waited until a manufacturer offered a perfectly open device, they'd have to wait until GNU Hurd ships on a phone... j/k
  - seba_dos1 8y ago
    Well, of course, not having to deal with distributing and handling the firmware in your OS is a very nice bonus. However, I could have worded myself better: FSF's RYF certification actually isn't about "downloadable firmwares", it's about "upgradable firmwares". IOW, if the user is able to install the software by themselves, the preinstalled one must be free, period - and no closed alternatives can be advertised or suggested. Redpine releasing a tool to flash the proprietary firmware would likely make the Librem 5's RYF certification void, which is a thing that IMO isn't helpful to anyone involved. Openmoko already went through that route, although AFAIR there was no formal RYF programme yet back then. Freerunner was all fine from FSF PoV until Openmoko released a firmware upgrade for the Calypso baseband that fixed some ugly bugs, suddenly making it not free enough for FSF. Which is especially funny considering that it basically opened the way to run OsmocomBB on that thing.

abrowne 8y ago

I believe the FSF position is that non-updatable firmware can be considered "part of the hardware", while updatable firmware cannot. I think they're concerned that updated firmware could change how the device functions in ways you can't control.

btashton 8y ago
Except that I am almost 100% certain [1] that they are using the RS9113 which as I suspected IS updateable (in some cases wirelessly) [2]. In fact in the Linux Firmware tree they have multiple firmware images depending on how you want the device to function. [3] >The host MCU can update the RS9113 module FW over UART using the kermit protocol or over SPI using the proprietary binary protocol. The default UART baud rate is 115200 kbps 8N1 with xon/off or no flow control. For baud rate >900000, hardware flow control must be used. Refer to the WiSeConnect PRM for more info - the "Upgrading the Firmware in Module" section discusses the SPI mode and "Firmware Upgradation" section discusses the UART mode. [1] https://source.puri.sm/bob.ham/image-builder/commit/856c9caf647aca14edfb125fb86b94ddb1240287 https://source.puri.sm/bob.ham/image-builder/commit/856c9caf... [2] http://www.redpinesignals.com/faqs.php http://www.redpinesignals.com/faqs.php [3] https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/commit/rsi?id=c1aa76a28c8031f747f6589e9b0f5aca8924a5e7 https://git.kernel.org/pub/scm/linux/kernel/git/firmware/lin...

bubblethink 8y ago

There are a lot of games overall. They made this entire post about how using a blob on a co-processor is fine because FSF guidelines have an exception for that. So after some gymnastics, you can make it look like your main processor needs no blobs. I don't know how they wrote this article with a straight face: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/ https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd...

confounded 8y ago
What would you propose they do?
- bubblethink 8y ago
  Live with the blob, and accept that the certification is quite meaningless if you have to do such gymnastics to get it.
  - madez 8y ago
    I disagree. Requiring it puts pressure on the manufacturers to do it better and be more open.
    - snaky 8y ago
      Loading the blob by M4 core instead of A53 core don't put any pressure on the manufacturers.
      - madez 8y ago
        Just letting another chip do the loading seems to be only part of the solution. The other part is to load it from read-only memory so it cannot be modified after production. That is what I consider to be the crucial property: the firmware must not be updateable.
        8y ago

seba_dos1 8y ago

I understand why FSF has this "no downloadable firmware" rule (they have to put a line somewhere), and I'm by all means a 100% Free Software zealot, but I honestly believe that this rule simply makes it not worth pursuing FSF certification in a device like a mobile phone, as you're ending up with actually less freedom as a user and no way to verify that it's really worth it (after all, a possibility to upgrade your firmware may simply be undocumented and you have no way to be sure that it's not there).

sounds 8y ago
Just speaking as one free software lover to another, I am happier that the Redpine Signal doesn't need downloadable firmware to function. It means that there will be just one version of firmware shipped. Just one version of firmware that the whole community will focus on analyzing, patching (only for the librem phone, it's only pure chance if that helps any other device), and if a patch is needed: * Redpine can either tell the entire community how to flash the firmware, or else the egg is on their face for shipping a broken firmware. * (There's basically no chance that the Redpine chip is actually not field-upgradeable if you have the right vendor tool and probably also a windows box to run the tool on.) The rest of the world seems to think, "flash it every time it boots up and I don't really care where that binary blob came from." I'll also just add, I can respect your position. Thanks for supporting Free Software, and I get it that there's value to being able to upgrade. That's kind of what I'm hoping happens later, if (cough, cough, when) there's a bug or exploit or worse. If purism waited until a manufacturer offered a perfectly open device, they'd have to wait until GNU Hurd ships on a phone... j/k
- seba_dos1 8y ago
  Well, of course, not having to deal with distributing and handling the firmware in your OS is a very nice bonus. However, I could have worded myself better: FSF's RYF certification actually isn't about "downloadable firmwares", it's about "upgradable firmwares". IOW, if the user is able to install the software by themselves, the preinstalled one must be free, period - and no closed alternatives can be advertised or suggested. Redpine releasing a tool to flash the proprietary firmware would likely make the Librem 5's RYF certification void, which is a thing that IMO isn't helpful to anyone involved. Openmoko already went through that route, although AFAIR there was no formal RYF programme yet back then. Freerunner was all fine from FSF PoV until Openmoko released a firmware upgrade for the Calypso baseband that fixed some ugly bugs, suddenly making it not free enough for FSF. Which is especially funny considering that it basically opened the way to run OsmocomBB on that thing.