4 ms·

In fact, having FSF validation doesn't prove anything but rather may be detrimental, because the FSF validation has built-in backdoors, and Purism took full adv

In fact, having FSF validation doesn't prove anything but rather may be detrimental, because the FSF validation has built-in backdoors, and Purism took full advantage of them - reducing user freedom in the process. Thread on how the Librem 5 is explicitly designed to hide proprietary blobs from the user in order to gain RYF certification (where having those blobs readily accessible would be strictly an improvement in freedom, as it would mean you are free to verify their contents, audit them, and potentially replace them with a free version if you develop one): https://twitter.com/marcan42/status/1040626210999431168 https://twitter.com/marcan42/status/1040626210999431168 Make no mistake, Purism has gone quite far down the freedom marketing religion path laid down by the FSF. They no longer care whether you're free or not, they care that you believe you're free. If you have blobs, stick them in /lib/firmware. Don't go hiding them in separate flash chips that I can't audit or rewrite just so you can slap the FSF's meaningless "the main CPU didn't touch any blobs (except the bootrom but we don't talk about that) so it doesn't have the digital cooties" rubber stamp on your device.

fsflover 6y ago
This thread is just wrong. You can modify the blobs if you need to: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/12 https://forums.puri.sm/t/does-respects-your-freedom-certific....
- marcan_42 6y ago
  The Librem article I linked in my thread clearly states: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/ https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... > The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing. The post you link to is full of wishy-washy fluff, but does not answer the direct question that the user posed in the OP, about the DDR timing code flash being writable.
  - fsflover 6y ago
    I don't see any "wishy-washy fluff". It states quite clearly: we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose. In other words, you can modify the firmware on the Wi-Fi card or modem. Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system. Edit: > can’t be modified without the user knowing > without the user knowing Did you actually read what you quoted?
    - marcan_42 6y ago
      > Methods to flash the firmware on the Librem 5 are outside of my area of expertise. That's CSO code for "I have no idea what I'm talking about, but I'm just giving you a canned response about our principles with no technical details and hoping you don't pry further and prove me wrong". He never explicitly addressed the RAM blob. If he knew it was flashable he would've outright said it to answer the question. But he did not. > Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system. Incorrect. The code is loaded in the DDR PHY. It then runs continuously. It is required for normal operation. This is because LPDDR requires continuous runtime re-training at its higher performance modes. What only runs on boot is the (dumb as hell) code they wrote to run on the Cortex-M4 as a workaround, because the FSF's ridiculous requirements forbid you not just from running proprietary code on the main CPU, but from touching proprietary code on the main CPU. So Purism built code that runs on cpu A to run code they built that runs on cpu B to load a blob from external read-only memory C into cpu D, just so they could claim cpu A never got digital cooties from touching the blob. Please appreciate the stupidity of this entire ordeal. cpu B code: https://source.puri.sm/Librem5/Cortex_M4/-/blob/master/ddr_loader.c https://source.puri.sm/Librem5/Cortex_M4/-/blob/master/ddr_l... > read only Means it can't be modified without the user knowing, and it also can't be modified with the user knowing. Unless the Librem 5 literally has a DIP switch for "enable flashing RAM code", read only means read only, period. It means the write protect pin is tied to protected, or a set-only protect bit in the SPI flash config was flipped.
holri 6y ago
You are wrong, from https://ryf.fsf.org/about/criteria https://ryf.fsf.org/about/criteria : "We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification."
- a1369209993 6y ago
  Do they actually enforce that, if the device can either have a proprietary blob that is user-updateable, or a proprietary blob that is not user-updateable, it must use the design where the proprietary blob is user-updateable? Because other claims by the FSF (namely, that non-updateable blobs can be treated as part of the hardware) directly contradict that.
deleted 6y ago
[deleted]

fsflover 6y ago

This thread is just wrong. You can modify the blobs if you need to: https://forums.puri.sm/t/does-respects-your-freedom-certification-allow-updating-of-proprietary-firmware/9484/12 https://forums.puri.sm/t/does-respects-your-freedom-certific....

marcan_42 6y ago
The Librem article I linked in my thread clearly states: https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/ https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurd... > The SPI flash will be read only so the firmware blobs can’t be modified without the user knowing. The post you link to is full of wishy-washy fluff, but does not answer the direct question that the user posed in the OP, about the DDR timing code flash being writable.
- fsflover 6y ago
  I don't see any "wishy-washy fluff". It states quite clearly: we do not institute any kind of write-lock or burnt fuses that would prevent the owner of the hardware from reflashing it with whatever firmware (new or otherwise) they choose. In other words, you can modify the firmware on the Wi-Fi card or modem. Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system. Edit: > can’t be modified without the user knowing > without the user knowing Did you actually read what you quoted?
  - marcan_42 6y ago
    > Methods to flash the firmware on the Librem 5 are outside of my area of expertise. That's CSO code for "I have no idea what I'm talking about, but I'm just giving you a canned response about our principles with no technical details and hoping you don't pry further and prove me wrong". He never explicitly addressed the RAM blob. If he knew it was flashable he would've outright said it to answer the question. But he did not. > Concerning the RAM, I do not see any problem with that, since there is no proprietary code running after the booting. As FSF says, it can simply be considered as a part of "hardware" which is necessary for the start of the system. Incorrect. The code is loaded in the DDR PHY. It then runs continuously. It is required for normal operation. This is because LPDDR requires continuous runtime re-training at its higher performance modes. What only runs on boot is the (dumb as hell) code they wrote to run on the Cortex-M4 as a workaround, because the FSF's ridiculous requirements forbid you not just from running proprietary code on the main CPU, but from touching proprietary code on the main CPU. So Purism built code that runs on cpu A to run code they built that runs on cpu B to load a blob from external read-only memory C into cpu D, just so they could claim cpu A never got digital cooties from touching the blob. Please appreciate the stupidity of this entire ordeal. cpu B code: https://source.puri.sm/Librem5/Cortex_M4/-/blob/master/ddr_loader.c https://source.puri.sm/Librem5/Cortex_M4/-/blob/master/ddr_l... > read only Means it can't be modified without the user knowing, and it also can't be modified with the user knowing. Unless the Librem 5 literally has a DIP switch for "enable flashing RAM code", read only means read only, period. It means the write protect pin is tied to protected, or a set-only protect bit in the SPI flash config was flipped.

holri 6y ago

You are wrong, from https://ryf.fsf.org/about/criteria https://ryf.fsf.org/about/criteria : "We want users to be able to upgrade and control the software at as many levels as possible. If and when free software becomes available for use on a certain secondary processor, we will expect certified products to adopt it within a reasonable period of time. This can be done in the next model of the product, if there is a new model within a reasonable period of time. If this is not done, we will eventually withdraw the certification."

a1369209993 6y ago
Do they actually enforce that, if the device can either have a proprietary blob that is user-updateable, or a proprietary blob that is not user-updateable, it must use the design where the proprietary blob is user-updateable? Because other claims by the FSF (namely, that non-updateable blobs can be treated as part of the hardware) directly contradict that.

deleted 6y ago

[deleted]