Those people are already running arbitrary binary code without the possibility to check what's inside, it's just that it was loaded before purchase. If you don't trust Intel's updates, then you also can't trust their CPUs in the first place.
There is a bit more nuance here though. There may be users who trust their old systems but no longer trust the current state of its manufacturer or their binary only updates. Proprietary blobs go against the core freedom as defined by FSF so I can understand why they block by default but IMO they should allow informed users to override. Simply censoring without allowing a user to bypass is not user (or freedom) respecting. The power to choose should be with the user, whom the FSF claims to represent.
Just because some proprietary code exists doesn't mean you should leave the door open for them to add as much extra proprietary code as they wish.
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.
You can't add much to a CPU via microcode. The space of what updates can do is extremely limited, with a limited amount of patch RAM and patch registers. It's designed to fix bugs. You're arguing against fixing bugs in proprietary software you're already running.
And yet that terrible security situation has approximately nothing to do with the FSF's "no visible blobs" rule. ME could be just as bad running off of ROM, and then it'd meet the FSF's "Respects your Freedom" requirements.
The issue is that the FSF fine with that binary blobs as long as it's stored in ROM, but if it's in RAM, that's bad. To me that is completely backwards. If a driver loads firmware into RAM, that means I have easy access to the blob, can reverse engineer it, update it and change it. If it's ROM that's going to be a lot more difficult or impossible.
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.
Your theory makes sense, but practice strikes me as the reverse: Long-term: Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes. Stuff in RAM? Always changing and "under attack" all the time.
Firmware in RAM is loaded from distribution packages, which also goes through a trackable process. There is a continuum here with frequent firmware updates being extremely dodgy (why can't they get it right and release a stable version), and infrequent updates (eg CPU microcode) being similar to shipping one image in "ROM".
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.
> Stuff in ROM is significantly easier to track because it happens slower, mostly by large trackable entities and processes.
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.
exactly. and people promoting closed source security updates should print this risk out in most clear fashion. if we want to hold GNU to account for security then we should definitely do so with closed source vendors too
I doubt that. While the attack was possible on large hosting providers, utilizing the same on workstations or hardmetal and actually get important data was basically impossible.
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.
Guix will never prevent you from doing what you want with your hardware. Nor will it give you software that is not properly free (as in freedom).
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.
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.
If the kernel can't load it without code changes and recompilation, due to the de-blobbing process, it doesn't make much sense to recommend to users that they load it.
At that point why just not power off their machines? That 3 websites that has “free js” is almost as useless as a brick. Also, free software in itself never protected against security vulnerabilities, many eyes is a fallacy.
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.