Hacker News Reader

Comment by r283492 | Hacker News Reader

About the microcode: the argument is basically "It is good nonfree software, just give up and accept it." Sorry? This is FSF. And no, it is not always good: https://www.theregister.com/2018/08/21/intel_cpu_patch_licen..., and when people don't accept it, https://www.theregister.com/2018/08/23/intel_microcode_licen.... If a majority of intel's customers said: sorry, we'll find other solutions rather than accepting your nonfree license, intel would freely license it.

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

There is CCC security presentation floating around where someone reversed engineered microcode before it was signed, and designed a backdoor into it, a remote code execution triggered by going to a specific webpage. That is a substantial capability that exists in todays microcode.

View on HN

> It is good nonfree software, just give up and accept it.

You already accepted it when you bought the CPU and it came with the base version. Your choices are to install a bugfix, or not. The FSF advocates for not installing the bugfix, or even informing users of the possibility of doing so. That is utterly illogical. There is no reason whatsoever to run broken proprietary software over fixed proprietary software.

> You already accepted it when you bought the CPU and it came with the base version.

No, that is a version you can't physically modify. The other version is one you can't modify because of it's license and signature verification. You are simply ignoring important differences, like saying an elevator is no different than a flight of stairs, they both get you up, and anyone who avoids elevators must be an idiot.

... but you can modify the base version. That's how microcode updates work, they patch it (via a patch register CAM). Are you trying to argue that the physical mechanism used for patching matters? That's an implementation detail, it has nothing to do with freedom.

Your CPU comes with patchable proprietary software. Period.

> ... but you can modify the base version.

There is some read-only memory that contains the base version. It is executed on boot. You can tell the cpu to run a different version by pointing it to a different version during the boot process (or later). You can't change the version in the read-only memory.

That's not how it works.

The way it works is that the microcode update gets loaded into some (smaller) RAM next to the ROM, and then patch registers are loaded which virtually rewrite some ROM locations to jump to the RAM (at least for the duration of this boot), in order to update the broken bits.

You are literally hot-patching the ROM with an overlay. You are not replacing it wholesale.

And either way, as I said, the underlying technical mechanism is completely irrelevant for the purposes of assessing user freedom. You're running proprietary code. You could be running a less buggy version of the same proprietary code. Choosing not to is silly and only hurts you. Trying to take that option away from users of your software is anti-freedom.

If the FSF thinks that even having proprietary blobs is bad, why does the rule apply only to mutable copies? Why not just refuse to certify devices with hardware that contains blobs contrary to their values? There's no practical argument as to why it's only acceptable to allow a nonfree blob if it's not burned into silicon. Even if it did matter, from the perspective of a normal person, microcode in a chip versus microcode loaded after boot offers no meaningful distinction in functionality or freedoms. If the point is high standards, then why have this loophole at all?

If the answer is "because then nothing could be certified or recommended" (which I expect it would be) then you need to stop marketing the certification as a recommendation for actual people to buy hardware and instead market it as a certification of whether the product is in line with their ideals.

Reply on news.ycombinator.com