Binary Blob Extermination Policy
9 November 2026
Article published by: GNU Leah Rowe™
Date of publication: 9 November 2026
RBoot is a wholly Free Software coreboot distro. The page you’re reading now, will attempt to describe how RBoot achives this goal, specifically, on a technical level. Some nuance is always present, in any such effort, so it’s critical that users do understand this.
Projects like coreboot are nominally free software, but may still contain some non-free software. RBoot takes projects like this and integrates them, with blobs removed; some patching is also done. We can’t support as much hardware because of this, but that’s the point of RBoot: to be a pure free software distribution.
RBoot, then, is a a much stricter approach to the same problem, of how to provide users with fully free boot firmware. It is strict, to the point of being pedantic, but it provides a viable solution for Free Software purists.
The policy that you are about to read is RBoot’s analog of the GNU Free System Distribution Guidelines as the FSDG criteria pertains only to operating systems; while it can be interpreted in the context of free boot firmware, an actual policy needed to be written for the firmware, hence this policy page that you are now reading.
Free as in freedom!
RBoot intentionally de-blobs coreboot, which is to say that it does not include binary blobs. The coreboot software otherwise requires binary blobs on some of the systems that it has support for. RBoot’s version of coreboot is entirely free, on its consequently reduced set of supported motherboards.
It was decided that a formal policy should be written, because there is quite a bit of nuance that would otherwise not be covered. RBoot’s policies in this regard were previously ill defined.
So what is RBoot’s policy?
RBoot follows a very conservative and light touch approach, when it comes to deblobbing coreboot.
RBoot only excludes software binary blobs, plus CPU microcode updates. Config data is more lax; for example, there’s no other way to provide SPD configuration for raminit training than by providing binaries - in a well-understood format - defining the timings and so on for the RAM. Thus, non-code blobs are overlooked so long as they otherwise come under a free and unencumbered license.
In practise, it is mostly microcode updates that RBoot’s build system deletes, along with coreboot Git history so that no traces remain of old revisions; older revisions had many blobs in the main repository, but modern coreboot moved almost all of them to third party submodule repositories..
Occasionally we might find blobs used by drivers, mostly network drivers; for example, RBoot removes the Realtek r8152 firmware blobs in U-Boot, modifying the driver such that it continues to operating (albeit in a reduced capacity) without the blob.
Non-software blobs are permitted, so long as they are in an easily understood and/or well-documented format. For example, DDR training data is permitted (patterns used during memory controller initialization, specifically training, where the precise timings for the RAM are brute-forced); this is not software.
SPD data stored in the coreboot Git repository is in all cases some format that’s simply more efficient to store as a binary, in a format that is in fact known/understood (see: coreboot source code and data sheets); in many cases, there’s only one correct way to write such data, making even the question of copyright a moot point. Data is data, and code is code; the two are separate.
Non-software blobs must be redistributable under a free license, and must not be encumbered by DRM, or they will not be included in RBoot.
Yes, these points were repeated, just to drive the point; proprietary software is bad. Data is data. Finally, there must not be any DRM; for example, it’s all well and good to to say that the data is free but if a system of DRM imposes restrictions on modifying it, even if it’s a free system, that is suspect and likely grounds for removal in RBoot.
Other firmware, such as Embedded Controller firmware, is currently outside the scope of the RBoot project, but not due to lack of desire; rather, these are not yet possible on most supported or otherwise capable platforms, at least not with free software. Other examples of firmware outside of the main boot flash is covered in the RBoot FAQ.
More detailed insight about microcode
To be clear: it is preferable that microcode be free. The microcode on Intel and AMD systems are non-free. Facts and feelings rarely coincide; the purpose of this section is to spread facts, regardless of the ideological assumptions made by the reader. RBoot wants CPU microcode to be free, but it almost never is, and so RBoot has a simple policy: remove it.
The CPU already has microcode burned into mask ROM. The microcode configures logic gates in the CPU, to implement an instruction set, via special decoders which are fixed-function; it is not possible, for example, to implement a RISCV ISA on an otherwise x86 processor. It is only possible for the microcode to implement x86, or broken x86, and the default microcode is almost always broken x86 on Intel/AMD CPUs; it is inevitable, due to the complexity of these processors.
These processors provide a way to supply microcode updates. These updates are volatile, and consequently must be applied during every boot cycle. The updates fix stability/reliability/security bugs, and their absence is technically incorrect, but RBoot excludes them anyway, because that is Canoe policy. Examples of where these updates fix bugs: on ASUS KCMA-D8/KGPE-D16 and ThinkPad X200/T400/T500/W500/X200T/X200/R500/X301, the updates make hardware-based virtualization (via kvm) completely stable, where it would otherwise lead to a kernel panic. They allow those same thinkpads to be run with high CPU usage and I/O (RAM usage), without crashing (otherwise, it’s very likely to encounter a kernel panic caused by a Machine Check Exception).
Not including these updates will result in an unstable/undefined state. Intel themselves define which bugs affect which CPUs, and they define workarounds, or provide fixes in microcode. Based on this, software such as the kernel, Linux, can work around those bugs/quirks. Also, upstream versions of Linux can update the microcode at boot time (however, it is recommend still to do it from coreboot, for more stable memory controller initialization or “raminit”). Similar can be said about AMD CPUs.
Again: facts. Some might argue that you may as well just use them, since the CPU already has microcode burned in. You may very well say that! RBoot could not possibly comment, but here are some specific technical examples of where RBoot has to mitigate bugs caused by a lack of microcode updates:
These patches revert bug fixes in coreboot, fixes that happen to break other functionality but only when microcode updates are excluded. The most technically correct solution is to not apply the above patches, and instead supply microcode updates! However, this would violate RBoot’s policy. RBoot ships without them, despite these facts - and they are facts. Another example: on AMD Opteron 62xx/42xx CPUs, not including microcode updates may allow code running inside virtual machines to access host memory; microcode updates fix this (63xx/43xx doesn’t have this bug).
Such mitigations aren’t always possible. For example, i945 CPUs often have thermal safety issues without microcode updates; they may overheat more dangerously than with them (based on reading Intel errata). This is a fact. Lack of microcode updates can cause bugs like this.
The general rule is to assume that your CPU is broken, and not secure, when excluding microcode updates. These updates patch bugs and fix security issues in CPUs, as per errata provided by Intel and AMD. Please consult the errata provided by Intel/AMD for your particular CPU. Please note that the ARM64 CPUs do not use microcode updates, because the logic gates are hard-wired; Intel/AMD CPUs allow to partially reconfigure logic gates via these microcode updates (that’s what the updates do, toggle gates).
It is imperative that users be warned about the facts, regardless of the ideology, due to the very nature of what microcode does. For example if you’re running mission-critical systems and you want to reduce the chance of data corruption, excluding microcode updates is ill advised; yet some people may take the risk. RBoot’s purpose is to be a fully free firmware distribution, but we will obviously provide such warnings as it is simply the right thing to do. Be wary of these caveats, when using RBoot.
Just to make you acutely aware, the above section will be summarised:
RBoot ships firmware that may cause your CPU to have major bugs, which would be unpatched when using RBoot. It’s not like these CPUs aren’t safety-tested at the factory, but CPUs are complex and hard to get right; the manufacturer will make them updateable via microcode, so that bugs can be fixed after production. Often, these updates are applied before the CPUs over hit store shelves, thus it could be argued that at least those updates are to be considered part of the main product; still, RBoot will not distribute them.
In practise, most users don’t really report many issues. All of this is to say that not applying bug fixes to your CPU’s operations may cause actual reliability, security and safety issues. There is no avoiding this fact. All of this is true, even if the system otherwise seems to work - computers that process instructions poorly will do so just as fastly as computers that process them correctly, and a lot of these bugs can be subtle, appearing only under certain edge case scenarios.
Markdown file for this page: https://rboot.org/news/policy.md
This HTML page was generated by the Rboot Static Site Generator.