Well, for some people loading an arbitrary binary code without possibility to check what's inside it is a critical security issue as well.
You can regard it as two separate features: one that's needed for the CPU to function, and another that's the door for more code being added. In that perspective it's better to go with preventing additions.
If there are issues with what are initially released and you do not patch you do not get those fixes.
So they could add stuff but they definitely will fix stuff. Not updating could be more dangerous then updating.
Sure it would be nice to have it all Free Software, but then we shouldn't treat hardware as a magic black box we don't care about.
Furthermore, I haven't seen any device that actually ships significant (ie non-bootloader) firmware in "ROM". It's usually in flash, meaning its contents are mutable but less legible to the Free system than if they were loaded every time by a Free driver.
Assuming you're able to track it at all. If the hardware does not provide any way to read the blobs, then how do you track anything? Decap your CPU and stick it under an electron microscope? Much easier to inspect a file on my filesystem.
Free software isn't about each of us individually fixing the problems. Nearly exactly the opposite.
I agree, if that's the position of Guix, I don't want it in my machine.
It had to be fixed, but your thesis that anyone was actually owned by these security issues because they didn't want to apply the mitigation rounds to at most 0.0% with an infinite amount of zeros before a 1.
The "nonguix" channel mentioned in the article does have Intel and AMD microcode for users who want it. This is similar to Debian, where you have to opt-in by enabling the "nonfree" repository and "apt install" the microcode package corresponding to your CPU.
> where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode
Is not ok
https://news.ycombinator.com/item?id=29290087
...at least, I don't see any such code in the actual deblobbing script: https://linux-libre.fsfla.org/pub/linux-libre/releases/5.15....
edit: since you called linux-libre a "fork", I feel compelled to point out that Linux-Libre is just the vanilla Linux kernel with that script applied. No more, no less.
# Do no recommend non-Free microcode update.
announce X86_LOCAL_APIC - Undocumented
clean_blob arch/x86/kernel/apic/apic.c
clean_kconfig arch/x86/Kconfig X86_LOCAL_APIC
clean_mk CONFIG_X86_LOCAL_APIC arch/x86/kernel/apic/MakefileLibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.
Can you buy anything at all on the internet?
If attackers who cannot add a comment to their exploit are in your threat model.
Personally, I've been using a browser extension that blocks JS unless it has a comment reading
> This code is NOT evil or malicious!
at the top. Haven't been hacked yet!
https://9to5mac.com/2021/03/11/browser-based-attack-affects-...
Turns out you don't need Turing completeness to perform microarchitectural side channel attacks. This is yet another way in which the "all my software is free, therefore I am safe from attacks" fallacy breaks down.
Nevermind that, as pointed out by other replies, LibreJS provides zero security. It relies on scripts voluntarily declaring that they're freely licensed, and if they do, they're allowed to run. The extension doesn't care whether the script is malicious or not.
I am still safe.