lbwww/site/news/gm45microcode.md

% GM45 no-microcode bug mitigations re-added (ThinkPad X200, T400 etc)
% Leah Rowe
% 17 April 2023

The change described in this article is *not* present in Libreboot 20221214,
20230319 or 20230413 - it will be present in the *next* Libreboot release.

If you want a no-microcode setup, either [build the
latest Libreboot from source via lbmk](../docs/build/) and remove the microcode
updates using the instructions on this page, *or* if you need pre-built ROM
images, Libreboot 20220710 had no-microcode ROMs by default and it has the
mitigation patches described by this article.

Introduction
============

Microcode updates provide stability and security fixes, using the files
provided by coreboot, which are assembled at boot time. CPUs have microcode
in them which configures the logic gates that implement an instruction set
architecture (the x86/x86\_64 architecture), and CPUs provide a *volatile*
mechanism for hot-patching it at boot time, which coreboot makes use of.

Libreboot *includes* CPU microcode updates *by default*, on all x86 hardware.
This *includes* boards that it supported prior to the new policy enacted last
year; before the policy change, Libreboot *excluded* these updates (but the
code for loading them *was retained*, so you could manually add them yourself
if you wanted to). Adding and removing them can be done by coreboot, at build
time, or you can add/remove them from the compiled ROM image by
running `cbfstool`; you can learn how to add/remove microcode updates here:
[How to add/remove microcode on coreboot images](../freedom-status.md#intelx86)

You can learn *why* they're needed, and about microcode in general, by reading
the [Binary Blobs Reduction Policy](policy.md) - it is a pragmatic policy,
enacted on 15 November 2022 with a view to supporting as *much* hardware as
possible from coreboot, reducing or eliminating binary blobs in the boot
flash and mitigating any issues that arise - for example, Libreboot makes use
of `me_cleaner` on some newer Intel platforms. You can read more about how the
policy is executed by reading the [Freedom Status](../freedom-status.md) page.

I've received some feedback about this, specifically by users of GM45-era
ThinkPads (X200, T400, T500, W500, R500, R400, X301, X200S/X200T, T400S and
R500). On *those* machines, if you [remove microcode
updates](../freedom-status.html#intelx86), it would break SpeedStep (CPU
frequency scaling) and the machine won't *reboot* properly (turning off and on
would work). Additionally, the machine would crash on lots of I/O (CPU cycles
and memory usage), due to a *Machine Check Exception* state leading to kernel
panic in your operating system; this last issue does not have a known fix,
except to update the microcode (which newer Libreboot releases do, by default).

Libreboot contained mitigations for broken SpeedStep/reboot, in older releases,
but it was decided that these mitigations would be *excluded* from the new
releases which include microcode updates by default; why mitigate a problem
that no longer exists in Libreboot?

Why indeed.

Mitigations patches restored!
-----------------------------

*I've restored these mitigations to Libreboot, as of today.*

The patch re-adding these mitigations can be seen here:

<https://browse.libreboot.org/lbmk.git/commit/?id=bd4ea9a02845b22a09b73ebb015ce134234d100b>

Why?
----

Free choice, that's why. We don't lecture anyone. We just help people.

One aspect of Libreboot policy is that Libreboot must be *configurable*. In
practise, some users want to remove microcode updates regardless of the
problems that it would cause. Even if I disagree with their reasoning, I
respect their decision and this change is designed to accomodate them.

in practise, such users had a choice before but they currently do not, in
recent Libreboot releases. This criticism was raised with me, and I've taken
it to heart. Therefore, users now have a choice; they always did, but remember:

Libreboot is aimed at non-technical users. Libreboot needs to be usable by
them. It needs to *work*. It *does* work, very well, when microcode updates
are included, as they are by default these days. This patch is about harm
reduction, to at least smooth things over for a small handful of users who
decide to remove microcode updates (as is their choice).

This change, today, fixes a practical violation of Libreboot policy by once
again restoring such practical choice to the user. It is already said how to
do so elsewhere, but I'll repeat it here in this news article for posterity:

How to add/remove microcode updates from ROM
--------------------------------------------

Extract to file on disk:

	cbfstool libreboot.rom extract -n cpu_microcode_blob.bin -f cpu_microcode_blob.bin

Remove:

	cbfstool libreboot.rom remove -n cpu_microcode_blob.bin

Add (if not present):

	cbfstool libreboot.rom add -f cpu_microcode_blob.bin -n cpu_microcode_blob.bin -t microcode

The `cbfstool` program can be compiled from `util/cbfstool/` in the coreboot
Git repository. In all recent Libreboot releases, you can find it
under `coreboot/default/util/cbfstool/`.

Regardless, the mitigations are largely harmless and so, I've restored them.
They are now included once again, in the Libreboot git repository and they
will be available in ROM images when the next release comes out.

I'll probably re-work the mitigation patch at some point, probably before the
next release, so that the mitigations are only applied if microcode updates
are absent. This would be checked for during machine initialisation, by
modifying the current patches accordingly.

That is all.