New article pertaining to CPU microcode updates
Signed-off-by: Leah Rowe <leah@libreboot.org>c20230710
Leah Rowe
parent
1a1a99a230
commit
a013235031
|
|
@ -1,3 +1,4 @@
|
||||||
|
microcode.md
|
||||||
audit.md
|
audit.md
|
||||||
e6400nvidia.md
|
e6400nvidia.md
|
||||||
libreboot20230423.md
|
libreboot20230423.md
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,168 @@
|
||||||
|
% No-microcode ROMs available in next Libreboot release (new stable release soon!)
|
||||||
|
% Leah Rowe
|
||||||
|
% 20 June 2023
|
||||||
|
|
||||||
|
As I write this, I'm quite close to providing a new stable release of Libreboot.
|
||||||
|
The final push to get it out the door is underway, with round-the-clock build
|
||||||
|
testing and general polishing.
|
||||||
|
|
||||||
|
Introduction
|
||||||
|
============
|
||||||
|
|
||||||
|
Firstly, what is microcode? In this context, CPU microcode is what configures
|
||||||
|
logic gates in the CPU to implement an instruction set. You can learn more
|
||||||
|
about microcode on the [FAQ](faq.md#microcode).
|
||||||
|
|
||||||
|
In the next Libreboot releases, ROM images that *exclude* CPU microcode updates
|
||||||
|
will once again be available. Libreboot's [Binary Blob Reduction
|
||||||
|
Policy](policy.md) dictates that each mainboard must be provided with as few
|
||||||
|
binary blobs as possible, ideally none. *At present*, *all* x86 and ARM
|
||||||
|
mainboards supported in Libreboot (in `lbmk.git` and in releases) can boot
|
||||||
|
with entirely free software, requiring *zero* blobs of any kind from *coreboot*.
|
||||||
|
|
||||||
|
The nuance of how Libreboot *implements* this policy is described in
|
||||||
|
the [Freedom Status](freedom-status.md) page. Although coreboot (which Libreboot
|
||||||
|
uses for hardware initialisation) *is* a free software project, certain binary
|
||||||
|
blobs are needed on some platforms, for things like raminit (memory controller
|
||||||
|
initialisation). Libreboot tries to reduce or eliminate these, or mitigate
|
||||||
|
their existence (for example, `me_cleaner` is used on newer Intel platforms).
|
||||||
|
|
||||||
|
One exception made in that policy is that CPU microcode updates *must* be
|
||||||
|
provided by default, on all x86 mainboards. The ARM platforms do not use
|
||||||
|
microcode at all. This is a correct policy, because these updates fix critical
|
||||||
|
security and stability issues in the silicon; more information about that
|
||||||
|
can be found [here](policy.md#more-detailed-insight-about-microcode). Since
|
||||||
|
the CPU already has older microcode burned into mask ROM, it makes logical
|
||||||
|
sense to install these updates to get the latest bug fixes.
|
||||||
|
|
||||||
|
In a previous news post,
|
||||||
|
titled [GM45 no-microcode bug mitigations re-added](gm45microcode.md), I
|
||||||
|
announced that Libreboot had re-added certain mitigations, working around bugs
|
||||||
|
caused when microcode is removed on certain Intel GM45 platforms (e.g. X200 or
|
||||||
|
T400 ThinkPads).
|
||||||
|
|
||||||
|
Why?
|
||||||
|
----
|
||||||
|
|
||||||
|
Freedom of choice, that's why. Libreboot's policy explicitly
|
||||||
|
[states](policy.md#configuration), in the context of *adding* binary blobs:
|
||||||
|
|
||||||
|
*It’s natural that the user may want to create a setup that is less libre than
|
||||||
|
the default one in libreboot. This is perfectly acceptable; freedom is superior,
|
||||||
|
and should be encouraged, but the user’s freedom to choose should also be
|
||||||
|
respected, and accomodated.*
|
||||||
|
|
||||||
|
Well, this change simply applies that *principle* in reverse. Roughly speaking:
|
||||||
|
|
||||||
|
It's natural that some people may wish to cause random kernel panics, raminit
|
||||||
|
failures, thermal safety issues, random data corruption in memory, and other
|
||||||
|
similar issues commonly caused by lack of microcode updates. Such folly should
|
||||||
|
be discouraged, but the user's *freedom to choose* should also be respected,
|
||||||
|
and accomodated.
|
||||||
|
|
||||||
|
It is the official view of the Libreboot project that microcode updates do not
|
||||||
|
even quality as *software*. The burned-in microcode *is* software, but the
|
||||||
|
updates only provide hotpatching, essentially turning on or off certain
|
||||||
|
features. The CPU already has older, buggier microcode burned into mask ROM,
|
||||||
|
so the choice is to either update it, or encounter more bugs. Regardless,
|
||||||
|
this is a point of contention for some people.
|
||||||
|
|
||||||
|
How?
|
||||||
|
----
|
||||||
|
|
||||||
|
The change was implemented by [this
|
||||||
|
patch](https://browse.libreboot.org/lbmk.git/commit/?id=f338697b96757977d2a14da00a91236595704fed)
|
||||||
|
on 19 June 2023, in the Libreboot build system.
|
||||||
|
|
||||||
|
In `board.cfg` for each mainboard defined (in Libreboot's build system, lbmk),
|
||||||
|
the following entries are available:
|
||||||
|
|
||||||
|
* `microcode_required="n" or "y"` (it's "n" on ALL boards)
|
||||||
|
* `blobs_required="n" or "y"`("n" on MOST boards)
|
||||||
|
|
||||||
|
If `blobs_required="n"`, the given ROM image `filename.rom`
|
||||||
|
becomes `filename_noblobs.bin` for all versions of it. In this
|
||||||
|
context, *noblobs* means *zero* blobs in the entire boot flash when the
|
||||||
|
final ROM image is flashed to it, regardless of whether coreboot is
|
||||||
|
blob-free, irrespective of microcode updates. ROM images
|
||||||
|
containing `noblobs` in the filename *may* still contain microcode
|
||||||
|
updates, distinguishing *microcode* as a special kind of blob distinct
|
||||||
|
from all others.
|
||||||
|
|
||||||
|
With or without `_noblobs` in the name:
|
||||||
|
|
||||||
|
If `microcode_required="n"`, the given ROM image `filename.rom`
|
||||||
|
is either:
|
||||||
|
|
||||||
|
* If no microcode blob exists within it already, such as on ARM
|
||||||
|
mainboards, the ROM is simply copied to: `filename_nomicrocode.rom`
|
||||||
|
* If the ROM contains microcode (default on most x86 boards, except Qemu
|
||||||
|
or in rare cases where none are advised), `filename.rom` is retained and
|
||||||
|
is copied to `filename_nomicrocode.rom`, and the CPU microcode update blob
|
||||||
|
shall be removed from `filename_nomicrocode.rom`.
|
||||||
|
|
||||||
|
What this means is that ROMs *with* OR *without* microcode will be present,
|
||||||
|
where applicable, on ROM images for each given mainboard. This will be the case
|
||||||
|
by default, for ROM images provided in the next release of Libreboot and all
|
||||||
|
releases that follow.
|
||||||
|
|
||||||
|
Example:
|
||||||
|
|
||||||
|
* `seabios_e6400_4mb_libgfxinit_txtmode_noblobs.rom`
|
||||||
|
* `seabios_e6400_4mb_libgfxinit_txtmode_noblobs_nomicrocode.rom`
|
||||||
|
|
||||||
|
It is *strongly* recommended, by the Libreboot project, that you
|
||||||
|
do *not* use the `_nomicrocode` ROMs on x86 mainboards. These updates
|
||||||
|
are *required* to implement stable x86 ISA, otherwise your CPU will behave
|
||||||
|
in strange, unpredictable ways, which could cause severe bugs in software
|
||||||
|
that cause *real* issues. Issues such as data loss.
|
||||||
|
|
||||||
|
A small but vocal minority of users are unhappy with the presence of these
|
||||||
|
microcode files, so it has been decided that the Libreboot project will once
|
||||||
|
again accomodate such users. This change has been implemented in the most
|
||||||
|
unintrusive way possible, to keep the build system logic clean, contrary to the
|
||||||
|
bloat that existed in many older Libreboot releases.
|
||||||
|
|
||||||
|
In previous releases of Libreboot, no-microcode was the default (microcode
|
||||||
|
updates were excluded entirely, from all releases). This policy was changed
|
||||||
|
during November 2022, as part of an ongoing campaign to support more hardware
|
||||||
|
(from coreboot) within Libreboot, so as to provide many more people with
|
||||||
|
coreboot which, regardless of blob status on each platform, *does* provide
|
||||||
|
increased software freedom compared to fully proprietary boot firmware, which
|
||||||
|
is what people would otherwise use; thus, Libreboot's modern policy is
|
||||||
|
pragmatic, advancing further the cause of *software freedom*.
|
||||||
|
|
||||||
|
By contrast, Libreboot's previous policy was to *ban all binary blobs*, which
|
||||||
|
meant that many mainboards from coreboot were excluded. This resulted in less
|
||||||
|
people achieving a level of software freedom, because to this day, nothing
|
||||||
|
quite like Libreboot exists with the scope and ambition that it has. Libreboot
|
||||||
|
makes coreboot as easy to use as possible for normal, non-technical people who
|
||||||
|
like the idea of coreboot, but are not competent to configure it from scratch.
|
||||||
|
|
||||||
|
Accordingly, the old Libreboot policy, prior to November 2022, *harmed* the
|
||||||
|
Free Software movement. Such harm was *corrected* in November 2022 and, going
|
||||||
|
forward, it is the intention of the Libreboot project to eventually have
|
||||||
|
build targets *for every mainboard that coreboot supports!*
|
||||||
|
|
||||||
|
ARM platforms
|
||||||
|
-------------
|
||||||
|
|
||||||
|
On ARM platforms, microcode is not used at all, so the `nomicrocode`
|
||||||
|
ROM images there are named simply according to what is already
|
||||||
|
the case.
|
||||||
|
|
||||||
|
Removing microcode also possible on older releases
|
||||||
|
==================================================
|
||||||
|
|
||||||
|
Libreboot releases *before* 20221214 excluded microcode by default, and did
|
||||||
|
not provide ROMs *with* microcode.
|
||||||
|
|
||||||
|
Libreboot 20221214, 20230319, 20230413 and 20230423 *include* microcode by
|
||||||
|
default, and do not provide no-microcode ROM images; however, removal is quite
|
||||||
|
simple:
|
||||||
|
|
||||||
|
cbfstool libreboot.rom remove -n cpu_microcode_blob.bin
|
||||||
|
|
||||||
|
Flash the resulting image. Again, expect *bugs*.
|
||||||
|
|
||||||
|
That is all.
|
||||||
Loading…
Reference in New Issue