Binäre Blob Reduktions Richtlinie

Leah Rowe

4 January 2022 (updated 15 November 2022)

English | Deutsch | українська

Verzeichnis

Autor: Leah Rowe

Datum: 4 January 2022 (updated 15 November 2022)

Einleitung

Dieser Artikel beschreibt die Prinzipien die das Libreboot Projekt definieren. Für Informationen darüber wie diese Prinzipien in der Praxis angewendet werden, bitte lies diesen Artikel stattdessen: Software and hardware freedom status for each mainboard supported by Libreboot

Libreboot’s Richtlinie ist für jeden Benutzer so viel Software Freiheit zu bieten wie möglich, auf jeglichem Bit von unterstützter Hardware, und so viel Hardware von Coreboot zu unterstützen wie möglich; was dies bedeutet ist, dass Du die Möglichkeit haben solltest, jeglichen Quelltext, jegliche Dokumentation oder jegliche andere Ressource die Libreboot zu dem machen was es ist, zu lesen, zu modifizieren und zu teilen. Einfach geasgt, Du solltest Kontrolle haben über deine eigene Computernutzung.

Das Ziel von Libreboot ist es genau dies zu ermöglichen, und möglichst vielen Benutzern zu helfen, mittels Automation der Konfiguration, Kompilierung und Installation von coreboot für technisch-unerfahrene Benutzer, und dies weiter zu vereinfachen für den durchschnittlichen Benutzer indem benutzerfreundliche Anleitungen für alles zur Verfügung gestellt werden. Grundsätzlich, Libreboot ist eine coreboot Distribution, ähnlich wie Alpine Linux eine Linux Distribution ist!

Der Zweck diese Dokuments ist, zu skizzieren wie dies erzielt wird, und wie das Projekt auf dieser Basis operiert. Dieses Dokument ist hauptsächlich über die Ideologie und ist daher (größtenteils) nicht-technisch; für technische Informationen schau in die Libreboot build system documentation.

Derzeitiger Projektrahmen

Das Libreboot Projekt ist besorgt um das was in den Haupt Boot Flash IC geht, aber es gibt andere Firmware Teile welche in Betracht gezogen werden sollten, wie erläutert im libreboot FAQ.

Die kritischsten hiervon sind:

Was ist ein binärer Blob?

Ein binärer Blob, in diesem Zusammenhang, ist jegliches Ausführbares für welches kein Quelltext existiert, welchen Du nicht in einer angemessenen Form lesen und modifizieren darfst. Per Definition sind all diese Blobs proprietärer Natur und sollten vermieden werden.

Bestimmte binäre Blobs sind ebenso problematisch, auf den meisten Coreboot Systemen, aber sie unterscheiden sich von Maschine zu Maschine. Lies mehr unter FAQ, oder auf dieser Seite wie wir mit diesen binären Blobs im Libreboot Projekt umgehen.

Für Informationen über die Intel Management Engine und AMD PSP, schau unter FAQ.

Blob reduction policy

Default configurations

Coreboot, upon which Libreboot is based, is mostly libre software but does require vendor files on some platforms. A most common example might be raminit (memory controller initialisation) or video framebuffer initialisation. The coreboot firmware uses certain vendor code for some of these tasks, on some mainboards, but some mainboards from coreboot can be initialised with 100% libre source code, which you can inspect, and compile for your use.

Libreboot deals with this situation in a strict and principled way. The nature of this is what you’re about to read.

The libreboot project has the following policy:

Generally speaking, common sense is applied. For example, an exception to the minimalization might be if vendor raminit and libre raminit are possible, but the libre one is so broken so as to be unusable. In that situation, the vendor one should be used instead, because otherwise the user might switch back to an otherwise fully proprietary system, instead of using coreboot (via libreboot). Some freedom is better than none.

Libreboot’s pragmatic policies will inevitably result in more people becoming coreboot developers in the future, by acting as that crucial bridge between it and non-technical people who just need a bit of help to get started.

Configuration

The principles above should apply to default configurations. However, libreboot is to be configurable, allowing the user to do whatever they like.

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.

In other words, do not lecture the user. Just try to help them with their problem! The goal of the libreboot project is simply to make coreboot more accessible for otherwise non-technical users.

FREEDOM CATALOG

A freedom status page should also be made available, educating people about the software freedom status on each machine supported by the Libreboot build system. Please read: Software and hardware freedom status for each mainboard supported by Libreboot.

It is desirable to see a world where all hardware and software is libre, under the same ideology as the Libreboot project. Hardware!?

Yes, hardware. RISC-V is a great example of a modern attempt at libre hardware, often called Open Source Hardware. It is a an ISA for the manufacture of a microprocessor. Many real-world implementations of it already exist, that can be used, and there will only be more.

Such hardware is still in its infancy. We should start a project that will catalog the status of various efforts, including at the hardware level (even the silicon level). Movements like OSHW and Right To Repair are extremely important, including to our own movement which otherwise will typically think less about hardware freedoms (even though it really, really should!)

One day, we will live in a world where anyone can get their own chips made, including CPUs but also every other type of IC. Efforts to make homemade chip fabrication a reality are now in their infancy, but such efforts do exist, for example, the work done by Sam Zeloof and the Libre Silicon project:

(Sam literally makes CPUs in his garage)

Problems with RYF criteria

Libreboot previously complied with FSF RYF criteria, but it now adheres to a much more pragmatic policy aimed at providing more freedom to more people, in a more pragmatic way. You can read those guidelines by following this URL:

Put simply, the RYF guidelines pertain to commercial products, with the stipulation that they must not contain proprietary software, or known privacy issues like backdoors.

The total exclusion of all proprietary software is currently not feasible. For example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices like HDDs or SSDs, and the like. The FSF RYF guidelines state the following exception, to mitigate this fact:

This 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 definition of product software is completely arbitrary; software is software, and software should always be libre. 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 libre, 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 perfect.

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.

Libre 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 ability to study, adapt, share and use/re-use software freely is important, 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.

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 encourage people to free it, on every laptop!

Other firmware currently outside the reach of the libreboot project are covered in the libreboot FAQ page. 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 the Libreboot build system does. At the moment, the Libreboot build system concerns itself just with coreboot (and payloads), but this ought to change in the future.

Examples of FSF sweeping blobs under the rug

Over the years, there have been numerous cases where the FSF actively fails to provide incentive for levels of software freedom, such as:

In all of the above cases, the FSF could have been stricter, and bolder, by insisting that these additional problems for freedom were solved. They did not. There are many other examples of this, but the purpose of this article is not to list all of them (otherwise, a book could be written on the subject).

Problems with FSDG

The FSF maintains another set of criteria, dubbed Free System Distribution Guidelines (GNU FSDG)]

The FSDG criteria is separate from RYF, but has similar problems. FSDG is what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans all proprietary software, including device firmware. This may seem noble, but it’s extremely problematic in the context of firmware. Food for thought:

Besides this, FSDG seems OK. Any libre operating system should ideally not have proprietary drivers or applications.

Hardware manufacturers like to shove everything into firmware because their product is often poorly designed, so they later want to provide workarounds in firmware to fix issues. In many cases, a device will already have firmware on it but require an update supplied to it by your OS kernel.

The most common example of proprietary firmware in Linux is for wifi devices. This is an interesting use-case scenario, with source code, because it could be used for owner-controlled software defined radio.

The Debian way is ideal. The Debian GNU+Linux distribution is entirely libre by default, and they include extra firmware if needed, which they have in a separate repository containing it. If you only want firmware, it is trivial to get installer images with it included, or add that to your installed system. They tell you how to do it, which means that they are helping people to get some freedom rather than none. This is an inherently pragmatic way to do things, and it’s now how Libreboot does it.

More context regarding Debian is available in this blog post: https://blog.einval.com/2022/04/19#firmware-what-do-we-do - in it, the author, a prominent Debian developer, makes excellent points about device firmware similar to the (Libreboot) article that you’re reading now. It’s worth a read! As of October 2022, Debian has voted to include device firmware by default, in following Debian releases. It used to be that Debian excluded such firmware, but allowed you to add it.

OpenBSD is very much the same, but they’re clever about it: during the initial boot, after installation, it tells you exactly what firmware is needed and updates that for you. It’s handled in a very transparent way, by their fw_update program which you can read about here:

https://man.openbsd.org/fw_update

Banning linux-firmware specifically is a threat to freedom in the long term, because new users of GNU+Linux might be discouraged from using the OS if their hardware doesn’t work. You might say: just buy new hardware! This is often not possible for users, and the user might not have the skill to reverse engineer it either.

More detailed insight about microcode

Releases after 20230423 will provide separate ROM images with microcode excluded, alongside the default ones that include microcode.

To be clear: it is preferable that microcode be libre. The microcode on Intel and AMD systems are proprietary. Facts and feelings rarely coincide; the purpose of this section is to spread facts.

The libreboot build system now enables microcode updates by default.

Not including CPU microcode updates is an absolute disaster for system stability and security.

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.

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

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. Not adding the updates is irresponsible, and ultimately futile, because you still end up with proprietary microcode, but you just get an older, buggier version instead!

This shift in project policy does not affect your freedom at all, because you still otherwise have older, buggier microcode anyway. However, it does improve system reliability by including the updates!

Such pragmatic policy is superior to the dogma that Libreboot users once had to endure. Simply put, the Libreboot project aims to give users as much freedom as is possible for their hardware; this was always the case, but this mentality is now applied to [a lot] more hardware.

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 libre 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 Libre Software (Right To Hack) is critical!

OSHW and Right To Repair are not covered at all by RYF (FSF’s Respects Your Freedom criteria), the criteria which Libreboot previously complied 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. The libreboot project rejects those policies in their entirety, and instead takes a pragmatic approach.

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.

Sad truth: RYF actively encourages less freedom, by not being bold enough. It sets 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 proprietary 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 libre 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), which will define exactly what hardware and software issues exist on each device. Include Right to Repair and OSHW (including things like RISCV) in the most “ideal” standard machine; the gold standard is libre silicon, like what Sam Zeloof and others are working on nowadays.

This new set of criteria should not attempt to hide or ignore anything. It should encourage people to push the envelope and innovate, so that we can have much more freedom than is currently possible. Necessity is the mother of all invention, and freedom is an important goal in every aspect of life, not just computing.

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!

Other resources

Ariadne Conill’s RYF blog post

Ariadne Conill, security team chair of Alpine Linux, posted a very robust article about RYF, with similar points made when compared to this article. However, Ariadne goes into detail on several other examples of problems with the FSF RYF criteria; for example, it talks about the Novena product by Bunnie.

It’s worth a read! Link:

https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/

Markdown-Datei: https://libreboot.org/news/policy.de.md

RSS

Website karte

Diese HTML-Seite wurde von Untitled Static Site Generator erstellt.