They store the blob on write-protected SPI flash (because users must not have the freedom to modify any firmware they do wind up running), and write some code for the secondary CPU just so that the main CPU doesn't get digital cooties from (eeeeeew) touching the DDR4 code.
-
Show this thread
-
Keep in mind this isn't even about the secondary (or main) CPU *running* the firmware. The firmware is always run by an embedded processor in the DDR4 PHY anyway. This is just about having the main CPU never even *see* the firmware. See no evil, hear no evil, speak no evil.
1 reply 0 retweets 17 likesShow this thread -
So it doesn't matter that the DDR4 controller firmware has access to all RAM and obviously can pwn the main CPU at will. As long as you bury it in read-only memory, and make sure it never is accessed by the main CPU, the FSF will give your product their meaningless rubber stamp.
1 reply 1 retweet 19 likesShow this thread -
What if the firmware is backdoored? Who knows! You're not supposed to touch it from the main CPU, lest you get digital cooties (eeeeeeeew). Just don't think about it. Move on. Everything's Libre™ (except the parts you can't see). It'll be fine.
1 reply 0 retweets 13 likesShow this thread -
So yeah, screw you, FSF. I want that blob compiled into the main CPU's u-boot, from a freely downloadable blobs repo, where I can do whatever I damn well want with it. Which is the sane engineering approach, and the most user-freedom-respecting thing to do.
1 reply 1 retweet 35 likesShow this thread -
Link to the story from
@Puri_sm. The fact that their engineer had to design that horrible nonsense workaround with a straight face and write the blog post to top it all off makes me sad.https://puri.sm/posts/librem5-solving-the-first-fsf-ryf-hurdle/ …5 replies 3 retweets 36 likesShow this thread -
The secondary processor exemption is also used by
#libreboot laptops which have proprietary Embedded Controller firmware. The irony there is that they recommend running proprietary Lenovo BIOS to update that Embedded Controller firmware: https://libreboot.org/docs/hardware/#ec-update-on-i945-x60-t60-and-gm45-x200-t400-t500-r400-w500 …1 reply 0 retweets 3 likes -
Replying to @olddellian @Puri_sm
And microcode inside the CPU, and proprietary firmware inside the Librem 5's baseband module, and... Everything. I bet there are ~zero "RYF" devices not using that exception. It's doing real harm to user freedom. I want my baseband firmware in /lib/firmware, not some spiflash!
2 replies 0 retweets 3 likes -
This Tweet is unavailable.
-
Especially with the current environment, yes/no certifications really aren't that helpful; what would be better would be a third party analysis of: Is there proprietary code? Where is it stored and executed? Is it able to be updated? What access to the system does it have?
2 replies 0 retweets 0 likes
And how much code is it? What is the impact? I really couldn't care less about a couple kB of firmware in a dumb USB mouse, but I certainly do care about dozens of megabytes in a cellular baseband.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.