Software and hardware freedom status for each mainboard supported by Libreboot
I've written a page on the Libreboot website, defining in brutally thorough detail, exactly how Libreboot's *binary blob reduction policy* is executed:
https://libreboot.org/freedom-status.html
This had been on TODO for a while, and its presence is required per Libreboot project policy.
I'm happy to now comply with that part of my own policy. I hope this helps people understand a bit more about Libreboot, post-osboot-merge. I was regularly saying the same things on IRC and today I decided to write the article.
I decided to publish this link here, on the Trisquel forums, because a lot of the same people who engage with me in this topic (on IRC) post here.
I'm eager to hear people's thoughts. (see above linked article, warning: it's long)
I am a translator!
The FSF believes that these x86 microcode updates (on Intel/AMD) allow you to completely create a new CPU that is fundamentally different than x86. This is not true.
How is that relevant to whether non-free microcode updates are acceptable or not? Do you mean that non-free software is acceptable for any chip that is also doing some processing in circuitry? What is the logic here?
Not including CPU microcode updates is an absolute disaster for system stability and security.
I have not noticed any serious issue on my X200 using Libreboot from 2016 without microcode updates.
From what I heard, the issues that the microcode updates are supposed to address are related to speculative execution, where the CPU, by trying to be more efficient, leaves some things visible to another process, and to "solve" this, the updates are making the CPU less efficient, while such kind of an issue seems benign for anyone using their computer as a single-user machine to run only free software, probably the vast majority of users interested in Libreboot. Am I missing something here?
Well, it's relevant because a lot of people assume the microcode does a lot more than it actually does.
As for issues, you mentioned X200 so let's cover that. Without microcode updates, you will likely encounter these issues:
* Broken S3 suspend/resume, depending on stepping
* Machine Check Exception (results in kernel panic) - very random. your machine could crash after 4 minutes, 4 days or 4 weeks, but at some point it will just crash
* (without mitigations) broken speedstep (CPU stuck at one frequency) and broken rebooting
* (with mitigations) no peci support (admitedly a minor feature, and coreboot didn't have it for years anyway), broken smrr handling*
* random corruption of data in memory, in subtle ways that cannot be predicted
Considering that the CPU already has older, buggier microcode burned into mask ROM, I consider the updates acceptable. You're running microcode regardless, but the updates fix bugs.
I know you've read it yourself because you're quoting it, but (for your readers) here is the section I wrote about microcode, that you're quoting:
https://libreboot.org/news/policy.html#more-detailed-insight-about-microcode
*mitigations:
I am a translator!
Well, it's relevant because a lot of people assume the microcode does a lot more than it actually does.
I don't know what people assume on what the microcode can or cannot do, but this is obviously not an argument to say that microcode updates are acceptable.
Considering that the CPU already has older, buggier microcode burned into mask ROM, I consider the updates acceptable.
Whether the chip that can execute microcode already has any microcode or not makes no difference, the only question is whether the computer is usable at all without microcode updates or not. Your answer is that it is not and let's assume now that your answer is reasonable.
That the computer is unusable without the microcode updates is a perfectly meaningful argument. However, it would be more honest to admit openly that this is the only argument, all the rest is just creating confusion and that is a disservice to people interested in free software.
You are aguing that the FSF is hiding that some proprietary things are problematic, so that no one will try to reverse engineer them, but this is exactly what you are doing here with microcode.
"I don't know what people assume on what the microcode can or cannot do, but this is obviously not an argument to say that microcode updates are acceptable."
Right. Free software is based in ethics and morality, not in any technical thing, so the first step is determining whether they're acceptable from a free software point of view is throwing such arguments out because they're not relevant and can't affect the validity of an argument not based on them.
"The libreboot build system now enables microcode updates by default."
"The Debian way is ideal. The Debian GNU+Linux distribution is entirely libre by default, and they include extra firmware if needed, which they have in a separate repository containing it. If you only want firmware, it is trivial to get installer images with it included, or add that to your installed system. They tell you how to do it, which means that they are helping people to get some freedom rather than none. This is an inherently pragmatic way to do things, and it’s now how Libreboot does it."
https://libreboot.org/news/policy.html
This is no longer true for Debian by the way. Why is Libreboot even shipping non-free microcode by default, or at all, if it's available as a package in distros and seemingly not "ideal"?
The reasons why are written in the policy. See:
https://libreboot.org/news/policy.html#more-detailed-insight-about-microcode
While it's true that updating the microcode from the OS kernel (e.g. linux or bsd) is possible, it would be irresponsible to avoid doing so at the boot firmware.
For example, random issues with memory during init might even cause a system not to boot at all. Coreboot pulls down updates from Intel's public Git repository, so it's not like these files are special, they're the same files that everyone use.
There are cases where writing to certain registers (during boot) causes buggy behaviour without first loading the microcode, in such a way that loading afterwards makes little difference. So you could end up in a situation where loading it in coreboot is the only way to guarantee reliability. For example, look at this patch:
This patch *re-introduces* a bug in coreboot, to fix rebooting when microcode is absent. It's a bad patch. If you were to not load microcode in coreboot, without this mitigation, and then apply it from linux, your system still would not reboot, and applying this mitigation re-introduces old buggy behaviour in coreboot.
If you need to have them anyway, it's better to do it early on in the boot process.
So to answer your question directly: it's simply the right thing to do, for the user, to ensure that their CPU behaves *correctly* per specifications, and what the Linux kernel expects. Non-standard, unpredictable behaviour is inevitable, without these updates.
Remember that the microcode is present regardless, burned into mask ROM inside the CPU, so excluding the updates just means using a buggier version. It makes zero different to user freedom, whether these updates are included or not.