[roenxi]

> ...In other words, you can’t microcode update a CPU to add or substantially change capabilities...

> ... vulnerabilities such as Meltdown and Spectre, which were partially mitigated through a microcode update ...

Of these two snippets, only one can be true. Either opaque microcode updates can substantially change how a system performs, or they can't. These mitigations are major changes to how the processor works.

This post looks to me like a fairly typical "doesn't quite get what they mean by freedom" take, of which there are many (which is cool, freedom isn't everyone's cup of tea). The FSF has been quite consistent that if there is a choice to be made, the user should have a practical way of making that choice. If the manufacturer can change how a CPU works with a microcode update, the user should be able to as well.

The FSF has a clear role here. Their job is to say "this software is free, this software is not". People constantly call on them to compromise on that role in the name of security/convenience/helpfulness/strategic adoption concerns/the impractical nature of their stance. The FSF should and does ignore those people. They are a (slightly quirky, yes) moral lighthouse more than an adoption friendly technical project. This microcode is not free software and someone should be pointing that out and complaining about it. If the FSF isn't taking a stand against non-free microcode, who will?

[Jasper_]

A majority of microcode updates aren't actual code, but are programming large swaths of undocumented registers known as "chicken bits" which turn off functionality and affect system operation. You can see what a rough fix looks like in Linux patches for devices that don't get these microcode updates: https://lore.kernel.org/lkml/b4ad7273efbb0c60a6c93ae68f82a44...

No, the details of what these MSR registers do isn't public. But it's far from being code; it's simply rather tweaking a large switchboard of functionality which already existed on your CPU. It is not adding new features or code to the execution pipeline.

Modern process development pipelines are already far too long that a common thing to do is to put an experimental feature in all CPUs and only enable it with the right microcode and chicken bits when it works well enough for general use. It's not uncommon for new processor features to have a 5-6 lag from "first buggy implementation" to "general implementation".

[Avamander]

> Their job is to say "this software is free, this software is not".

But if they say "this software is free because the hardware is more locked down" then I don't see that as standing for user freedoms.

> People constantly call on them to compromise

It's about being more nuanced, not about making compromises.

[garaetjjte]

Yet they are fine with running microcode as long you don't update it. It doesn't make sense. Blobs don't disappear just because they are hidden in ROM.

[DarylZero]

Apparently it's OK because both the vendor and the user are prevented from updating it. Thus there's no power differential between them on that specific point.

[TT-392]

That one kinda makes sense, because, when you can't update it, there isn't really much of a practical difference between something implemented in hardware or firmware. So not allowing blobs in rom would almost be hypocritical if you don't also mandate that the actual silicon of the chip is completely free.