add new article: a formal policy document, regarding binary blobs

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)

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?
 ------------------------------------------------
 

site/news/MANIFEST

@@ -1,3 +1,4 @@
+policy.md
 translations.md
 libreboot20211122.md
 libreboot20210522.md

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

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:
+
+<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10.patch?id=9938fa14b1bf54db37c0c18bdfec051cae41448e>
+
+<https://browse.libreboot.org/lbmk.git/plain/resources/coreboot/default/patches/0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for-.patch?id=4b7be665968b67463ec36b9afc7e8736be0c9b51>
+
+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 <https://osboot.org/> - 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.