path: root/libreboot-policy.7

.Dd July 30, 2024
.Dt libreboot-policy 7
.Os "Libreboot"
.Sh NAME
.Pp
.Nm libreboot-policy
.Nd binary blob reduction policy
.
.Sh INTRODUCTION
.Pp
This article describes the principles that govern the Libreboot project. For
information about how those principles are applied in practise for each
mainboard, please refer for the pages for each mainboard. See
.Xr libreboot-hardware 7 .
.Pp
Libreboot's policy is to provide as much
.Lk https://writefreesoftware.org software freedom
as possible to each user, on each and every bit of hardware supported, and to
support as much hardware from coreboot as is feasible; what this means is that
you should have the potential to study, modify and share all source code,
documentation or other such resources that make Libreboot what it is. Put
simply, you should have control of your own computing.
.Pp
The goal of Libreboot is
to do exactly this, and help as many people as possible by automating the
configuration, compilation and installation of coreboot for non-technical
users, easing it further for the average user by providing user-friendly
instructions for everything. Essentially, Libreboot is a coreboot
distribution, in much the same way Alpine Linux is a Linux distribution!
.Pp
The purpose of this document it to outline how that is brought about, and how
the project operates along this basis. This document is largely about the
ideology and it is therefore (mostly) non-technical; for technical information,
you can refer to
.Xr libreboot-lbmk 7 .
.
.Sh PROJECT SCOPE
The libreboot project is concerned with what goes in the main boot flash IC, but
there are other pieces of firmware to take into consideration, as covered
in
.Xr libreboot-faq 7 .
.Bl -bullet -compact
.It
Embedded controller firmware
.It
HDD/SSD firmware
.It
Intel Management Engine / AMD PSP firmware
.El
.
.Ss What is a binary blob?
.Pp
A binary blob, in this context, is any executable for which no source code
exists, that you cannot study and modify in a reasonable manner. By definition,
all such blobs are *proprietary* in nature, and should be avoided if possible.
.Pp
For information about Intel Management Engine and AMD PSP, refer to the FAQ.
.
.Sh BLOB REDUCTION POLICY
.Ss Default configurations
.Pp
Coreboot, upon which Libreboot is based, is mostly libre software but does
require certain vendor code 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.
.Pp
Libreboot deals with this situation in a strict and principled way:
.Bl -bullet
.It
If free software can be used, it should be used. For example, if VGA ROM
initialization otherwise does a better job but coreboot has libre init code
for a given graphics device, that code should be used in libreboot, when
building a ROM image. Similarly, if memory controller initialization is
possible with vendor code or libre code in coreboot, the libre code
should be used in ROMs built by the Libreboot build system, and the vendor
raminit code should not be used; however, if no libre init code is available
for said raminit, it is permitted and Libreboot build system will use the
vendor code.
.It
Some nuance is to be observed: on some laptop or desktop configurations, it's
common that there will be two graphics devices (for example, an nvidia and
an intel chip, using nvidia optimus technology, on a laptop). It may be that
one of them has libre init code in coreboot, but the other one does not. It's
perfectly acceptable, and desirable, for libreboot to support both devices,
and accomodate the required vendor code on the one that lacks native
initialization.
.It
An exception is made for CPU microcode updates: they are permitted, and in
fact required as per libreboot policy. These updates fix CPU bugs, including
security bugs, and since the CPU already has non-libre microcode burned into
ROM anyway, the only choice is either x86 or broken x86. Thus, libreboot
will only allow coreboot mainboard configurations where microcode updates
are enabled, if available for the CPU on that mainboard.
However, releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode. See
.Xr libreboot-microcode 7 .
.It
Intel management engine: When possible, documentation must be written to tell
people how to neuter the ME, if possible. The
.Li me_cleaner
program is very useful, and provides a much more secure ME configuration.
.It
Vendor blobs should never be deleted, even if they are unused. In the
coreboot project, a set of `3rdparty` submodules are available, with vendor
code for init tasks on many boards. These must all be included in libreboot
releases, even if unused. That way, even if the Libreboot build system does
not yet integrate support for a given board, someone who downloads libreboot
can still make changes to their local version of the build system, if they
wish, to provide a configuration for their hardware.
.El
.Pp
Generally speaking, common sense is applied. For example, an exception to the
minimalization might be if vendor raminit and libre raminit are available, 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.
.Pp
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.
.Ss Configuration
.Pp
The principles above should apply to default configurations. However, libreboot
is to be configurable, allowing the user to do whatever they like.
.Pp
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; free software is
superior, and should be encouraged, but the user's freedom to choose should also
be respected, and accomodated.
.Pp
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.
.
.Sh LIBRE HARDWARE
.Pp
It is desirable to see a world where all hardware and software is libre, under
the same ideology as the Libreboot project.
.Pp
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.
.Pp
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!)
.Pp
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:
.Bl -bullet -compact
.It
.Lk https://www.youtube.com/channel/UC7E8-0Ou69hwScPW1_fQApA
.It
.Lk http://sam.zeloof.xyz
.It
.Lk https://libresilicon.com
.El
.Pp
(Sam literally makes CPUs in his garage)
.
.Sh SEE ALSO
.Bl -tag
.It Libreboot's main website
.Lk https://libreboot.org
.It Libreboot manual root
.Xr libreboot 7
.It Free Software
.Lk https://writefreesoftware.org
.El
.
.\" vim: tw=80