A 100% blob-free, Libre world would be nice. Unfortunately, that is not an achievable goal today. The FSF knows this. The solution they came up with? Make sure the user can't *see* any of the proprietary firmware. As long as they don't see it, nobody will complain. Brilliant.
-
Show this thread
-
So RYF has a "secondary processor exception". Which basically means that as long as proprietary firmware is stored separately from the Free™ part, and you can't touch it, and you're firewalled from it, Everything Is Peachy.
3 replies 0 retweets 26 likesShow this thread -
This is, of course, total crap. A device that respects user freedom is a device that *allows* the user to modify proprietary firmware, that *exposes* exactly what proprietary firmware is there, and that *encourages* reverse engineering to produce a Free version.
2 replies 4 retweets 45 likesShow this thread -
What *I* want is hardware with exactly as much proprietary firmware to make it practical (and no more), where all of it is in /lib/firmware (or equivalent). No secret flash memories. I can mess and reverse engineer it all. This is the exact opposite of what the FSF encourages.
1 reply 1 retweet 30 likesShow this thread -
Of course, you still want to be firewalled from devices using proprietary firmware wherever possible (in the form of interfaces that are secure, e.g. no free memory read/write from the blob), but that has nothing to do with not allowing the free side to send the blob over.
1 reply 0 retweets 16 likesShow this thread -
But RYF instead says you must hide and bury any firmware you end up having to have. And so
@Puri_sm end up having to do utter nonsense, like using a secondary CPU core to load the DDR4 controller firmware into the hardware, just so they can claim the binary blob is elsewhere.1 reply 0 retweets 21 likesShow this thread -
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.
1 reply 0 retweets 19 likesShow 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.
-
-
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 threadThanks. Twitter will use this to make your timeline better. UndoUndo
-
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.