diff --git a/site/footer.include b/site/footer.include index c8e4a06..108e010 100644 --- a/site/footer.include +++ b/site/footer.include @@ -1,6 +1,7 @@ ------------------------------------------------------------------------------- +* [Zero binary blob policy](/policy.md) * [Edit this page](/git.md) * [Who develops Libreboot?](/who.md) * [License](/license.md) diff --git a/site/index.md b/site/index.md index f1a0b03..dcf1211 100644 --- a/site/index.md +++ b/site/index.md @@ -43,6 +43,10 @@ handles only basic initialization and jumps to a separate an [automated build system](docs/build/) that builds complete *ROM images*, for more robust installation. Documentation is provided. +**Libreboot excludes binary blobs, shipping only Free Software and, as such, +only supports a handful of machines from coreboot. You can read Libreboot's +zero-blobs policy on the [Libreboot blob policy page](policy.md).** + How does Libreboot differ from regular coreboot? ------------------------------------------------ diff --git a/site/news/MANIFEST b/site/news/MANIFEST index db057ff..641c48b 100644 --- a/site/news/MANIFEST +++ b/site/news/MANIFEST @@ -1,3 +1,4 @@ +policy.md translations.md libreboot20211122.md libreboot20210522.md diff --git a/site/news/policy.md b/site/news/policy.md new file mode 100644 index 0000000..08d9b36 --- /dev/null +++ b/site/news/policy.md @@ -0,0 +1,22 @@ +% Formal policy established, regarding Libreboot's zero-blob policy +% Leah Rowe +% 2 January 2022 + +Libreboot intentionally *de-blobs* coreboot, which is to say that in does not +include binary blobs. It is a distribution of entirely Free Software and, as +such, only supports a handful of machines from coreboot, which otherwise +requires binary blobs on most systems. Libreboot's version of coreboot is +entirely *free*, on all supported mainboards. + +Libreboot is designed to comply with the Free Software Foundation's +[Respects Your Freedom criteria](https://ryf.fsf.org/about/criteria) and +the [GNU Free System Distribution (GNU FSDG) guidelines](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html), +ensuring that it is entirely [Free Software](https://www.gnu.org/philosophy/free-sw.html). + +Libreboot's operational policy regarding blobs has not changed, and will not +change, but it was previously unwritten, relying on assumptions based on +FSF criteria. Libreboot's policy is to comply with FSF policy, but there is a +lot of nuance involved: + +**[A formal set of guidelines / criteria are now available.](../policy.md) They +outline, in detail, Libreboot's precise policy, regarding binary blobs.** diff --git a/site/policy.md b/site/policy.md new file mode 100644 index 0000000..e0ae00a --- /dev/null +++ b/site/policy.md @@ -0,0 +1,416 @@ +--- +title: Binary blob policy +x-toc-enable: true +... + +This article was written by Leah Rowe, the founder and current lead developer +of Libreboot. + +Introduction +============ + +Libreboot intentionally *de-blobs* coreboot, which is to say that it does not +include binary blobs. The coreboot software otherwise requires binary blobs on +most systems that it has support for. Libreboot's version of coreboot is +entirely *free*, on its consequently reduced set of supported mainboards. + +Libreboot is designed to comply with the Free Software Foundation's +[Respects Your Freedom criteria](https://ryf.fsf.org/about/criteria) and +the [GNU Free System Distribution Guidelines (GNU FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html), +ensuring that it is entirely [Free Software](https://www.gnu.org/philosophy/free-sw.html). + +It was decided that a formal policy should be written, because there is quite +a bit of nuance that would otherwise not be covered. Libreboot's policies in +this regard were previously ill defined. + +Background information +====================== + +Libreboot concerns itself only with what goes in the main boot flash IC, but +there are other pieces of firmware to take into consideration, as covered +in the [Libreboot FAQ](faq.md#what-other-firmware-exists-outside-of-libreboot). + +Most critical of these are: + +* Embedded controller firmware +* HDD/SSD firmware +* Intel Management Engine / AMD PSP firmware + +Specific binary blobs are also problematic, on most coreboot systems, but they +differ per machine. Libreboot *excludes* binary blobs in releases, so it only +supports a handful of machines from coreboot. + +For information about Intel Management Engine and AMD PSP, refer to the FAQ. + +So what *is* Libreboot's policy? +================================ + +Libreboot follows a very conservative and *light touch* approach, when it comes +to deblobbing coreboot. It is a very *correct* approach. + +Libreboot only excludes *software* binary blobs, plus CPU microcode updates, +completely in line with FSF policy. *In practise, it is mostly microcode +updates that Libreboot'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.*. + +*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 Libreboot. + +Logic (in coreboot) for *loading or executing* binary blobs should not +be removed/disabled. Libreboot merely *excludes* the blobs themselves. Most +of the blobs that Libreboot removes (when downloading coreboot, in the build +system) are CPU microcode updates; Libreboot leaves the code for loading +microcode updates intact, and you can in fact insert microcode updates into +your ROM image. This behaviour is intentional, and must not be removed. The +only job Libreboot has is to not *distribute* those blobs itself! + +*That's all*. Furthermore, Libreboot must only support systems where *all* of +the main boot flash can be free. For example, ivybridge and sandybridge intel +platforms are completely libre in coreboot, but you still need neutered Intel +ME firmware in the flash, making those machines unsuitable for Libreboot. + +Other firmware, such as Embedded Controller firmware, is currently outside the +scope of the Libreboot 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 Libreboot FAQ. + +Problems with RYF criteria +========================== + +You can read those guidelines by following these hyperlinks: + +* [GNU Free System Distribution Guidelines (GNU FSDG)](https://www.gnu.org/distros/free-system-distribution-guidelines.en.html) +* [FSF Respects Your Freedom (RYF) guidelines](https://ryf.fsf.org/about/criteria) + +The FSF RYF guidelines state the following: + +*"However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."* + +This is absolute pure nonsense, and should be rejected on ideological grounds. +The rest of libreboot's policy and overall ideology expressed, in this article, +will be based largely on that rejection. The term *product software* is +completely asinine; software is software, and software should always be *free*. +Instead of making such exceptions, more hardware should be encouraged, with +help given to provide as much freedom as possible, while providing education +to users about any pitfalls they may encounter, and encourage freedom at all +levels. When an organisation like the FSF makes such bold exceptions as above, +it sends the wrong message, by telling people essentially to sweep these other +problems under the rug, just because they involve software that happens to run +on a "secondary processor". If the software is possible to update by the user, +then it should be free, regardless of whether the manufacturer *intended* for +it to be upgraded or not. Where it really *isn't* possible to update such +software, proprietary or not, advice should be given to that effect. Education +is important, and the FSF's criteria actively discourages such education; it +creates a false hope that everything is great and wonderful, just because the +software on one arbitrary level is all free. + +This view of the FSF's, as expressed in the quoted paragraph, assumes that +there is primarily *one* main processor controlling your system. On many +modern computers, this is *no longer true*. + +Free *software* does not exist in a vacuum, but we had less freedom in the +past, especially when it came to hardware, so *software* was our primary focus. + +[The four freedoms are absolute](https://www.gnu.org/philosophy/free-sw.html), +but there is a lot of nuance when it comes to *boot firmware*, nuance which is +largely non-existent outside of firmware development, or kernel development. +Most typical application/system software is high level and portable, but boot +firmware has to be written for each specific machine, and due to the way +hardware works, there are many trade-offs made, including by the FSF when +defining what standards should apply *in practise*. Different lines in different +sands. Different *battle grounds*. + +The fact that almost nobody talks about the EC firmware is *because* of the +Respects Your Freedom certification. In reality, the EC firmware is crucial +to user freedom, and ought to be free, but it is completely disregarded by +the FSF as *part of the hardware*. This is wrong, and the FSF should actively +actively encourage people to free it, on every laptop! + +Other firmware currently outside the reach of the Libreboot project are covered +in the Libreboot FAQ. For example, HDD/SSD firmware is covered in the FAQ. +Again, completely disregarded and shrugged off by the FSF. + +The Libreboot project will not hide or overlook these issues, because they are +indeed critical, but again, currently outside the scope of what lbmk does. +At the moment, lbmk concerns itself just with coreboot, but this ought to +change in the future. + +Examples of FSF inconsistency +============================= + +Another example of FSF inconsistency: the ThinkPad T400 supported by Libreboot, +often comes with both an ATI *and* Intel graphics chipset, but coreboot can be +configured to use one or the other. If using the ATI chipset, there is currently +no free initialization code available, but you can disable it and use the Intel +one, where completely free initialization code exists in coreboot, plus free +drivers in linux. Under strict interpretation of the RYF guidelines, the T400 +should not be endorsed by the FSF at all, but the FSF made an exception and +endorsed it *in configurations where the Intel chipset is used exclusively as +per software configuration*. They endorsed the T400 as sold by Leah Rowe, with +Libreboot pre-installed. + +To be clear: use of the ATI video chipset on a ThinkPad T400 currently requires +loading a proprietary *VGA option ROM*, loaded into the coreboot ROM image. +Libreboot simply disables that chip and uses coreboot's init code for the Intel +chip instead, with that chip in use exclusively. It can therefore be said that +the ThinkPad T400 is not fully usable in freedom, even by the FSF's conservative +standards. It is *especially* not free by Libreboot standards, because the EC +firmware is non-free, and it is a non-free hardware design, even if it is +nominally free with Libreboot installed. + +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 coincidence; the +purpose of this section is to spread *facts*. + +Libreboot will not include the updates, because FSF compliance is still a +policy, in spite of the FSF's flaws. Complying with a policy does not mean it +should be agreed with; it's possible in life to do things contrary to ones own +beliefs. However, this promise to the FSF is the only thing preventing it. +It would otherwise be perfectly acceptable for *CPU microcode updates* to be +inserted in Libreboot (and just microcode. no other blobs). Again: FSF RYF. + +Making matters worse, that very same text quoted from the FSF RYF criteria in +fact specifically mentions microcode. Quoted again for posterity: + +*"However, there is one exception for secondary embedded processors. The +exception applies to software delivered inside auxiliary and low-level +processors and FPGAs, within which software installation is not intended after +the user obtains the product. This can include, for instance, microcode inside +a processor, firmware built into an I/O device, or the gate pattern of an FPGA. +The software in such secondary processors does not count as product software."* + +Here, it is discussing the microcode that is burned into *mask ROM* on the CPU +itself. It is simultaneously not giving the OK for microcode *updates* supplied +by either coreboot or the Linux kernel; according to the FSF, these are an +attack on your freedom, but the older, buggier microcode burned into ROM is OK. +This is absolutely inconsistent. + +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. + +The basis of the FSF's disagreement about microcode *updates* is that they do +believe otherwise; Stallman himself expressed such ignorance to me, in a recent +email conversation I had with him, as of January 2nd, 2022. The FSF believes +that these x86 microcode updates (on Intel/AMD) allow you to completely create +a new CPU that is fundamentally different than x86. This is not true. It is also +not true that *all* instructions in x86 ISA are implemented with microcode. In +some cases, hardcoded circuitry is used! The microcode updates are more like +tiny one liner patches here and there in a git repository, by way of analogy. +To once again get in the head-space of the FSF: these updates cannot do the CPU +equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing +more! + +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/reliably/security bugs, and their *absence* +is *technically incorrect*, but Libreboot excludes them anyway, because that is +FSF 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](faq.html#machine-check-exceptions-on-some-montevina-penryn-cpu-laptops)). + +Leah Rowe policy is to include microcode updates, *by default*, because they +do not affect software freedom in practise, since the only other "choice" is +*broken, buggy* microcode. This is not a choice, it is a prison, and a less +comfortable prison is clearly inferior. + +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 Linux kernel +can work around those bugs/quirks. Also, upstream versions of the Linux kernel +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. + +Here are some examples of where lack of microcode updates affected Libreboot, +forcing Libreboot to work around changes made upstream in coreboot, changes +that were *good* and made coreboot behave in a more standards-compliant manner +as per Intel specifications. Libreboot had to *break* coreboot to retain +certain other functionalities, on some GM45/ICH9M thinkpads: + + + + + +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! + +Pick your poison. Libreboot does not disable the mechanism in coreboot to load +these updates. At boot time, coreboot can supply such updates to the CPU, if +present in CBFS. Libreboot merely excludes them, but you can add them to your +Libreboot ROM image. A fork of Libreboot, named osboot, includes them by +default; it does this, even on libreboot-compatible hardware. Not adding the +updates is *irresponsible*, but a promise was made to the FSF back in 2013 +when the Libreboot project started, precisely that it would not add microcode +to ROM images by default. It is Libreboot's policy to keep that promise. + +More info about osboot is available on - osboot's policy +is the same as Libreboot, except that it does *not* delete blobs; the goal is +still software freedom, but it provides those users who are not willing/able +to use libreboot hardware to otherwise still have some freedoms compared to +otherwise fully proprietary *vendor* firmware. osboot and libreboot are two +sides of a coin; libreboot is the "light", and osboot is the dark side. Both +projects are maintained and were founded by Leah Rowe. + +I am **this** close to adding microcode updates in Libreboot, on a weekly basis, +for *years*. The only reason I don't add them is due to my own stubborn refusal +to betray my original agreement with the FSF; I no longer have commercial ties +with them (my company, Minifree, now ships with osboot, not libreboot, even on +libreboot-compatible hardware, but still offers libreboot on request). I even +do quite well for myself, but still: I made a promise to FSF where *libreboot* +is concerned, and I decided that I would stick to the agreement. + +But I do not agree with that agreement. I never did. If you agree with my +assessment about microcode, I wholeheartedly recommend osboot instead of +Libreboot, on all libreboot-compatible hardware. + +My other reason that I will simply comply with FSF criteria is *precisely* +that osboot exists. I created it *specifically* because I do not agree with the +policy of Libreboot, my own project. I am horrified by the technically +incorrect monstrosity that I created, so I did osboot to make me feel better. +It is far superior to Libreboot, in every way, because it still can (*and does*) +support the same hardware, but it lacks dogma. The osboot project takes a more +pragmatic approach to freedom, that is completely in line with my action views. +*Libreboot is inferior*. + +However, I will say: + +People have been using Libreboot for years, on these machines, and most people +don't really have *that* many issues, most of the time. My opposition to FSF's +microcode policy is out of principle. *Logical*, common sense principle. I +simply cannot compute that microcode updates are an attack on your freedom, +because: + +Microcode updates are not an attack on your freedom. The FSF's opposition to +these updates is both symbolic and *ignorant*; it is ultimately futile, but I +digress. + +**I will continue to develop Libreboot and osboot, in parallel.** + +Moral of the story +================== + +Compromise and nuance is the name of the game, even if you're the FSF. As of +January 2nd, 2022, [Richard Stallman himself](http://web.archive.org/web/20220102082138/https://stallman.org/stallman-computing.html) +used a ThinkPad T400S with Libreboot installed onto it, with the Intel video +chipset in use. He may not even be aware of the issue with ATI chips, though it +should be said that T400*S* only ever comes with the Intel video chipset (not +ATI). The ATI chipset is only ever available on the regular T400! Libreboot +however would greatly benefit if those ATI chipsets had free init code in +coreboot, because then users could make use of that and have superior performance +for graphical applications, by using the ATI chip instead of the Intel one. +It is currently not possible to do that in freedom. + +Other considerations +-------------------- + +Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at +the silicon level would however be amazing, and efforts already exist; for +example, look at the RISCV ISA (in practise, actual fabrication is still +proprietary and not under your control, but RISCV is a completely free CPU +design that companies can use, instead of having to use proprietary ARM/x86 and +so on). Similarly, Right To Repair (ability to repair your own device, which +implies free access to schematics and diagrams) is critical, for the same +reason that Free Software (Right To Hack) is critical! + +There ought to be a defined scope, in any project, and Libreboot currently has +a very clearly defined scope, but it goes without saying that Libreboot could +be *improved* and *do more* in the future. *RYF is garbage, and should be +replaced; it is far too conservative by modern standards. FSDG is still OK.* + +OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your +Freedom criteria), the criteria which Libreboot was created to comply with. +RYF also makes several concessions that are ultimately damaging, such as +the *software as circuitry* policy which is, frankly, nonsensical. ROM is still +software. There was a time when the FSF didn't consider BIOS software a freedom +issue, just because it was burned onto a mask ROM instead of *flashed*; those +FSF policies ignore the fact that, with adequate soldering skills, it is trivial +to replace stand-alone mask ROM ICs with compatible flash memory. + +Conclusion +========== + +RYF isn't *wrong* per se, just flawed. It is correct in some ways and if +complied with, the result *does* give many freedoms to the user, but RYF +completely disregards many things that are now possible, including freedoms at +the hardware level (the RYF criteria only covers *software*). Those guidelines +are written with assumptions that were still true in the 1990s, but the world +has since evolved. As of 2 January 2022, Libreboot still complies strictly with +RYF, and will continue to do so, at least for the time being. + +Facts and *feelings* are usually very different things, and contradictory. +Such is the nature of life. + +The conclusion that should be drawn from all of this is as follows: + +*Following* FSF criteria does not damage anything, but that criteria is very +conservative. Its exemptions should be *disregarded* and entirely ignored. +RYF is no longer fit for purpose, and should be rewritten to create +a *more strict* set of guidelines, without all the loopholes or exemptions. +As has always been the case, Libreboot tries to always go above and beyond, but +the Libreboot project does not see RYF as a *gold standard*. There are levels +of freedom possible now that the RYF guidelines do not cover at all, and in +some cases even actively discourage/dis-incentivize because it makes compromises +based on assumptions that are no longer true. + +Maintaining Libreboot, under the FSF's strict (and simultaneously lax: see +EC loophole) policies, is a fun technical challenge, and it is a *worthwhile* +pursuit. Having free boot firmware on the **host CPU** is very important!! +Freedom is important, at all levels, including what runs merely on the host +CPU, but that is not the *only* level to take into account. All levels should +be considered, and *explored*, with or without the FSF's strict requirement +(currently without). FSF currently looks at Libreboot and thinks that the work +is *done*, when that is far from true, precisely because of the EC firmware +and other freedom issues that remain, on all currently supported mainboards. + +Sad truth: RYF actively encourages *less* freedom, by not being bold enough. +It pitches a victory flag and says *mission accomplished*, despite the fact +that the work is *far* from complete! + +If followed *with exemptions unchallenged*, RYF may in some cases encourage +companies to *sweep under the rug* any freedom issues that exist, where it +concerns non-free firmware not running on the host CPU (such as the +Embedded Controller firmware). + +I propose that new guidelines be written, to replace RYF. These new guidelines +will do away with all exemptions/loopholes, and demand that *all* software be +free on the machine, or as much as possible. Instead of only promoting products +that meet some arbitrary standard, simply catalog all systems on a grand +*database* of sorts (like h-node.org, but better). Include Right to Repair and +OSHW (including things like RISCV) in the most "ideal" standard machine. + +Don't call it "Respects Your Freedom" or something similar. Instead, call it +something like: the freedom catalog. And actually focus on hardware, not just +software! + +In the year 2022 onwards, we can do better. The RYF program should be cancelled. +It is no longer fit for purpose. + +Think for yourself, and do not let perfection become the enemy of the good.