... yes, because your distro did the right thing and does provide updated packages and loads them for you (it's not persistent, but rather done on each boot), and thus you don't need to do anything and also don't see warnings about your distro failing to do so. Whereas linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode than letting you get tempted to use non-free updates to the non-free firmware in your CPU.

Yup, it's all about controlling users' access to hardware and software to fulfill some imaginary "freedom" ideal that doesn't actually have any relevance in reality.

Stallman personally refused to certify bunnie's Novena laptop (a fully open hardware and software laptop) as "Respects your Freedom" because there were no free drivers for the GPU, and although it wasn't going to ship with GPU acceleration (that's optional anyway), Stallman said users might be "tempted" to install the proprietary blob. Instead he suggested it might be possible to get the manufacturer to cripple the GPU (permanently fuse it off of existing chips that already have it), and then that could be RYF-certified.

bunnie gave up on that, but had he actually shipped a crippled FSF-approved version... a few years later, open drivers for that GPU were developed, so that would've made the regular version certifiable, and everyone who bought the "respects your freedom" version would've been left with needlessly crippled hardware. But the FSF insists this is the way to go.

Meanwhile, they're endorsing "Respects Your Freedom" Bluetooth dongles that have about half a megabyte of proprietary firmware in ROM.

> a few years later, open drivers for that GPU were developed

So ... FSF made the right call? What is the point of the certification of a device if there are no drivers for it.

The wrong call, because you can only reasonably develop drivers for uncrippled GPUs. The FSF was so caught up in maintaining a freedom from being _tempted_ to use proprietary software, that their solution would've taken away the freedom to develop your own free software.

I read the certification is some sort of consumer protection/advice. As a consumer, you would want to know the state of the device at purchase when you pay for the GPU. Not some maybe driver coming up in years.

It would be a kinda good idea to have a "rms would almost use this" sticker they could hand out, though.

Looking at: https://ryf.fsf.org/categories/laptops

There is a sorry collection of refurbished laptops.

> linux-libre doesn't want you to know if your distro isn't loading updated microcode, because it's "better" (according to them) to run vulnerable non-updated microcode

This is FUD. The reason it's not possible to load microcode or other proprietary blobs from linux-libre is because of a limitation of the deblobbing process. From [0]:

Indeed, I became aware that some users have got the idea that blocking the loading of blobs is a feature. It's not; it's just a bug that's quite difficult to fix. The decision on whether or not to use a piece of software, be it Free or not, should belong to the users, and it's not our intent to make that difficult.

If you can make the deblobbing script leave an escape hatch for users to load their own blobs, at their option, I'm sure the pull request would be well-received.

[0] https://www.fsfla.org/ikiwiki/blogs/lxo/2013-11-08-linux-lib...

Then why is the reasoning in the linked email given as

> Another significant change in this release is that it was pointed out that there were error messages in Linux suggesting users to update x86 CPU microcode. Since such microcode is non-Free Software, such messages don't belong in GNU Linux-libre.

That reads very much as "we don't want to encourage users to consider updating microcode". Your argument also seems unlikely since distros ship the microcode as an extra package that gets picked up by the kernel, so clearly the ability to not upload microcode if the user doesn't provide it is there. (It makes sense that is that way and a different situation than the drivers your link discusses, since the device runs without a microcode update, whereas peripherals that need blobs often won't run at all without them)

The deblobbing script includes an explicit section that censors the microcode update messages.

http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...

Grep for "Do no recommend non-Free microcode update" [sic].

The actual censoring patterns are here:

http://linux-libre.fsfla.org/pub/linux-libre/releases/5.15.3...

Grep for "arch/x86/kernel/apic/apic.c" to find some of them.

You might have, without realising it. It's supplied as a package in nearly every distro.

Here's the Debian package for the Intel microcode, for example:

https://packages.debian.org/bullseye/intel-microcode

Debian hides it away in their "non-free" repo but it's in the default install in many other distros.

To add, you can do:

    dmesg | grep "microcode updated early to"

To see when it was last updated.

Yes you have, it's done automatically.

serious question: why is something that is updated without you knowing about it ok?

Same way that it's ok that if you update your distro it fetches newer drivers, a new kernel and patched versions of all the software you installed? Microcode is loaded at runtime, it's not permanently modifying your system.

The question is still: are "magic incantations" in packages ok, considering that they allow the issuer to control your hardware more than if the code was baked into firmware just once?

Also, these packages allow vendors to keep quiet about security issues, because they can silently fix them in the next update.

Is it any more of a "magic incantation" than the linux-image-XYZ package which controls which OS kernel is installed? Or the linux-firmware package which controls what firmware gets loaded on various devices?

If you want to see when Intel issues new microcode updates, it is all available on their GitHub: https://github.com/intel/Intel-Linux-Processor-Microcode-Dat...

but i dont do that automatically, as the parent described. as far as i am aware i need to manually issue a comand to perform the update, which is ok as far as i have that control

Distros prompt you when upgrading packages, not binaries. You get a prompt to update Firefox package, not for replacing the actual binary on disk.

Typically packages including microcode behave the same way - prompt to update the package, no prompt to implement that update (replace individual files).

"automatically" as in "automatically when you update the rest of your distro", not an extra step as the poster above clearly seemed to expect. That context also was clearly from the other comments already.

i dont seem to be able to reply directly. my question was meant as a clarification because simply saying something is "automatic" is very ambiguous. "automatic" to me means giving up control. to me whats being described is not "automatic"

It's updated when you update all your other packages. It's no different from updating your shell or your desktop environment.

but i am aware when those updates happen and what they are. they are not automatic or hidden

It's just a package. It's not automatic nor hidden. If you've never noticed it being updated, then you probably haven't been paying enough attention to the package list when you did choose to issue a system-wide upgrade command.

Worth noting that BIOS updates frequently ship with ucode updates that are applied at boot before UEFI executes the operating system. So if GP is diligent about keeping the BIOS up to date, it's conceivable that Linux's ucode update has never had any work to do. At the very least this seems to be the case with Thinkpads.

What is that package called? Is it the "linux-firmware" one?

On Debian, https://packages.debian.org/bullseye/intel-microcode

The "updated microcode" package is installed on your system manually (like any other package). The "automatic" part comes in when your system boots up, after this package is installed. On boot, when the package is installed, your system will automatically use the installed package to update the processor's microcode.

if its not automatic or hidden then it is ok, as long as you have that control. to be clear i think GNU has every right to forbid non-free software just as anyone has the right to not use GNU software if they don't want to. what should be known about are consequences and responsibilities for either (any) decision. if GNU says we dont want to support this security update it needs to clearly state the risk their users face. if it does that then its ok as far as i am concerned

They do not state anything like that; that's the entire problem with that linux-libre patch. It is removing a message that informs user that their computer is at risk without an update, because they don't want people to know, because if they did most people would choose to install the proprietary update to the proprietary microcode they are already running, and that would expose the existence of that microcode, and the FSF's utopia only exists in the minds of people who aren't aware of all the proprietary firmware they're running anyway.

It's all a big lie. There's proprietary firmware everywhere. The FSF just doesn't want users to know about it, so they can live happily in their blissful ignorance believing they are freer than everyone else.

So is the microcode package and the loader that loads it. What kind of difference are you trying to make here?