GNU Linux-Libre 4.16 Released, Won't Warn You About Spectre/Meltdown Microcode Updates

[autonomous_cowherd]

Yeah, exactly, non-free software is okay as long as it cannot be replaced now?

There's no 'now' about it - that's been their view for many years. If you can't replace it then it's effectively part of the hardware, or so the argument goes. It wasn't new when it came up some years ago regarding one of the radio modules on the openmoko, and it didn't make much sense to me then either.

[autonomous_cowherd]

Yeah, exactly, non-free software is okay as long as it cannot be replaced now?

That's been their approach for many years. If you can't change it then it's effectively hardware not software. I first came across it regarding an issue with one of the openmoko wireless interfaces, and it didn't make much sense to me then either.

[sdack]

I for one dislike the messages of the standard kernel as it shows anyone booting up a system directly on the boot screen that it hasn't been compiled with the fixes. If the security flaws were of such an importance then it shouldn't be an option, and yet it is. I wonder if it isn't just the result of virtue signalling by some of the kernel devs. So now the message spams the boot screen where it only attracts unwanted attention, while not every single Linux machine on the planet needs to be 100% bullet proof.

[iugamarian]

Actually doing a firmware update on a Core I5-6400 disables (protect CPU from) the ability to overclock it by BCLK on Z170 board that has an older BIOs to allow it. And as admax88 and dungeon show you can be secure without firmware updates. So I actually really badly don't need firmware updates. BCLK overclock gives a stable 150% increase in CPU performance, can go up to 180% but it's then too stressed.

[R41N3R]

So rather than suggesting to update the non-free FW to something more secure, it would rather you stick with the old, less secure non-free FW that comes on the chip because suggesting a non-free firmware update would violate your freedom?

The logic seems incoherent to me.

EDIT: Better solution, rather than remove it, change the warning to something noting the HW is vulnerable.

Yes, it would have been better to warn the user that the non-free firmware of the specific hardware is vulnerable.

[waxhead]

Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.

Give the FSF a break. Some of them might be fanatic , but then again many of us here are fanatic about Linux, some filesystem, some programs. some harddisk brands etc etc...
There are far worse things in the world happening because of fanatics who even cut peoples head off, so for some to try to push for an ideal world where knowledge is shared (yes, programs are knowledge) is not really that bad is it?

Just imagine if Wikipedia suddenly closed for example? Let's be glad that someone tries to share knowledge for free. And besides, FSF made their goal right? Now people are talking about they not warning against vulnerable hardware which in itself is just one more reason to open up the code.

I will admit that they could have put up a warning. "hey, your hardware sucks, and because someone is not as idealistic as we are, we can't fix it either", that would have made more sense, but at least they get people talking until we are all on RISC-V hardware

[starshipeleven]

The FSF has always promoted extreme solutions because someone needs to show people just how much proprietary code runs on their systems. It's not a pragmatic approach, but no one expects it to be.

The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

But it sure is easy.

Just delete code and brand yourself as "defender of FOSS" or something.

This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

How about they do something more useful than just deleting code?

Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

Is this all FSF has become? A PETA equivalent for free software?

[starshipeleven]

Think they are doing disservice to their customers by not shipping blobs, if you have a choice between stock microcode that is known to be insecure and updated microcode that is known to implement mitigatio, choice should be fairly simple really. Purism is a nice ideal to strive for, but in the mean time choose lesser evil, please.

As others said, microcode updates aren't required to mitigate this particular case, so in this specific case it's not an issue.

Overall, I agree with you, you cannot run without microcode and running with outdated microcodes does not make your system more less free or freedom-respecting. It's like painting the fence yellow and then claiming that the yellow fence makes your PC respect your freedom more. Does not change anything.

[WolfpackN64]

The point here is that microcode is running anyway, inhibiting the update of what is loaded from UEFI or the ROM does not prove anything.

But it sure is easy.

Just delete code and brand yourself as "defender of FOSS" or something.

This is all bullshit I could do in 10 minutes myself by just deleting the firmware packages from my running system, and then rebooting.

How about they do something more useful than just deleting code?

Something that actually gives me hardware that respects my freedom instead of doing stupid cheap stunts that serve no purpose?

Is this all FSF has become? A PETA equivalent for free software?

No this is not all the FSF has become. Don't be daft.

[starshipeleven]

No this is not all the FSF has become. Don't be daft.

"Well, we are waiting."

Don't leave me hanging like this.