From a0132350311804e4d6bbf4f0d8c643498c43e0c7 Mon Sep 17 00:00:00 2001 From: Leah Rowe Date: Tue, 20 Jun 2023 05:32:06 +0100 Subject: [PATCH] New article pertaining to CPU microcode updates Signed-off-by: Leah Rowe --- site/news/MANIFEST | 1 + site/news/microcode.md | 168 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 169 insertions(+) create mode 100644 site/news/microcode.md diff --git a/site/news/MANIFEST b/site/news/MANIFEST index 34c0e57..a3b347b 100644 --- a/site/news/MANIFEST +++ b/site/news/MANIFEST @@ -1,3 +1,4 @@ +microcode.md audit.md e6400nvidia.md libreboot20230423.md diff --git a/site/news/microcode.md b/site/news/microcode.md new file mode 100644 index 0000000..041d3b6 --- /dev/null +++ b/site/news/microcode.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.