Conversation

Lol, that's an interesting take on security. We'll run on closed source microcode that is buggy because any updates are considered closed source. I mean, I'm kinda surprised they they haven't limited their supported arches to risc-v.
Quote Tweet
Again reminded of lists.gnu.org/archive/html/i, in which a GNU project removes a warning message informing users that their CPU microcode leaves them vulnerable to CPU microarchitectural attacks
Show this thread
1
4
Replying to
FSF is fine with closed source hardware and firmware. It's the ability to update closed source firmware that they're against. They're particularly opposed to it if there's signature verification of the firmware updates. They regularly endorse closed source hardware/firmware.
1
1
Replying to and
It's not the closed source firmware and hardware they have a problem with but rather the fact that the company is able to release updates for it but others cannot create them. If you block updating firmware, such as by breaking it in the efuse configuration, they'll endorse it.
1
1
Replying to and
So, for example, the Librem 5 is all about choosing hardware which has persistent firmware so that they don't need to load it from the OS. They go out of the way to prevent it from being updated too. That's the path they're taking to seeking FSF endorsement for their products.
2
Replying to
They're fine with motherboard firmware loading microcode as long as the motherboard firmware isn't being updated by the OS. They consider hardware non-free if it permits updating closed source microsode or motherboard firmware though. If it's disabled, they're fine with it.
1
1
Replying to and
They're against software 'recommending' that you use proprietary software and they include giving information on it, linking to it, offering tooling to work with it, etc. to be a recommendation. Those 'libre' distributions are primarily just stripping out optional features.
1