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.

So why don't CPU vendor open source their microcode? Secrets... ok, let's use the ones which have no secrets.

Good luck with that...

This is a double edge sword.

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.

Intel hardware definitely cannot be trusted. Probably "good enough" for most people, but it's honestly garbage, security wise.

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.

You're completely missing the fundamental point that all of this takes a proverbial village.

Free software isn't about each of us individually fixing the problems. Nearly exactly the opposite.

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

Yeah. Then these geniuses get bitten by Spectre/Meltdown because they were too scared of running the microcode update. For real.

I agree, if that's the position of Guix, I don't want it in my machine.

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.

Good to know, but still

> where this Linux fork actively removes security warnings informing users that they need to update their CPU microcode

Is not ok

I believe that argument is based on the same FUD that I addressed here:

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.

I'm sorry, but this (and a bunch of other similar blocks) seem pretty intentional...

    # 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/Makefile

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.

You can often also update your microcode by updating your BIOS/firmware.

That's a good point! Adjusting the message to direct people down that route rather than simply removing it seems like a good idea.

Sorry, but you are wrong. GNU people won't run nonfree JS at all.

LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run.

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.

You are really wrong, a lot of services (specially news) work either without JS or have a libre alternative, such as Twitter/Nitter, or Reddit/Teddit.

I use NoScript and I find very few sites that are really broken if I don't enable JS.

Your and mine definition of very few sites must be different than.

Can you buy anything at all on the internet?

Amazon not so long ago worked without JS, or Ebay, I can't remember.

"LibreJS is a good example in order to kill any potential Spectre/Meltdown attack. There is no attack when no code is being run."

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!

> There is no attack when no code is being run.

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.

Dillo has a nice CSS-less rendering. Also, Links+.

I am still safe.

But that is simply not the logical decision.