Return to index

Article published by: Leah Rowe

Date of publication: 20 June 2023

UPDATE: Libreboot 20230625 was released on 25 June 2023, and it contains the change described in the text below.

The original article text from 20 June 2023 is as follows:

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.

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 and here.

In the next Libreboot releases, ROM images that exclude CPU microcode updates will once again be available. Libreboot’s Binary Blob Reduction Policy 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 vendor files of any kind within coreboot.

The nuance of how Libreboot implements this policy is described in the Freedom Status page. Although coreboot (which Libreboot uses for hardware initialisation) is a free software project, certain vendor files 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. 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, 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).

Freedom of choice, that’s why. Libreboot’s policy explicitly states, in the context of adding vendor files:

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 qualify 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.

The change was implemented by this patch 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)
• vendorfiles="n" or "y"(“n” on MOST boards)

If vendorfiles="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 vendor file 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 file 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 file 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 freedom 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!

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.

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.

Markdown file for this page: https://libreboot.org/news/microcode.md

Subscribe to RSS for this site

Site map

This HTML page was generated by the Untitled Static Site Generator.