libreboot
/
lbwww
1
0
Fork 0
Code Packages Projects Releases Activity

further consolidate text in freedom status 

Signed-off-by: Leah Rowe <leah@libreboot.org>
c20230710
Leah Rowe 2023-06-20 19:01:43 +01:00
parent 78a99c7625
commit e66189f6c5
1 changed files with 83 additions and 124 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

207
site/freedom-status.md
View File

@ -6,18 +6,19 @@ x-toc-enable: true
Introduction Introduction
============ ============
As many readers may know, coreboot (which Libreboot uses for hardware This page documents how Libreboot's [binary blob reduction
initialisation) is nominally *Free As In Freedom*, *libre* or *open source* policy](news/policy.md), adopted in November 2022, is implemented in practise,
software; albeit, coreboot attempts to provide free code to initialise each especially that line which says: *"if a blob can be avoided, it must be
machine. The coreboot developers work tirelessly to reverse engineer as much avoided."*
functionality as possible, so as to provide freely licensed source code.
On *some* (not all) platforms, coreboot *requires* certain Libreboot uses [coreboot](https://coreboot.org/) for hardware initialisation.
[blobs](https://en.wikipedia.org/wiki/Binary_blob) for things While coreboot is nominally *free* or *open source* software, on *some* (not
like raminit. *All* boards currently supported by Libreboot can be initialised all) platforms, coreboot *requires* certain
entirely with *free*, *libre* or *open source* code from *coreboot* itself, [blobs](https://en.wikipedia.org/wiki/Binary_blob)
because Libreboot currently only focuses on such mainboards. Libreboot's goal is for things like raminit. *All* boards currently supported by Libreboot can be
to eventually support *all* mainboards from coreboot. initialised entirely with *free*, *libre* or *open source* code from *coreboot*
itself, because Libreboot currently only focuses on such mainboards. Libreboot's
goal is to eventually support *all* mainboards from coreboot.
A more *pragmatic* [binary blobs reduction policy](news/policy.md) was adopted A more *pragmatic* [binary blobs reduction policy](news/policy.md) was adopted
by Libreboot during November 2022, as part of an ongoing campaign to support by Libreboot during November 2022, as part of an ongoing campaign to support
@ -27,11 +28,6 @@ software freedom compared to fully proprietary boot firmware which is what most
people would otherwise use; Libreboot's modern policy is thus pragmatic, further people would otherwise use; Libreboot's modern policy is thus pragmatic, further
advancing the cause of *software freedom*. advancing the cause of *software freedom*.
This page documents how Libreboot's [binary blob reduction
policy](news/policy.md), adopted in November 2022, is implemented in practise,
especially that line which says: *"if a blob can be avoided, it must be
avoided."*
Libreboot's *previous* policy was to *ban all binary blobs*. This actively Libreboot's *previous* policy was to *ban all binary blobs*. This actively
*harmed* the Free Software movement, by reducing the number of people who can *harmed* the Free Software movement, by reducing the number of people who can
realistically use coreboot because, to this day, nothing quite like Libreboot realistically use coreboot because, to this day, nothing quite like Libreboot
@ -43,23 +39,13 @@ was *corrected*, in November 2022.
Coreboot architecture Coreboot architecture
--------------------- ---------------------
Although not *strictly* necessary for non-developers, you may find it useful For context about certain topics, please read:
to gain a high-level understanding of *how* coreboot works, to gain some
some context about some of the topics discussed in this article. See:
<https://doc.coreboot.org/getting_started/architecture.html> <https://doc.coreboot.org/getting_started/architecture.html>
100% libre init in coreboot 100% libre init in coreboot
=========================== ===========================
*All* mainboards currently supported by Libreboot can have 100%
libre initialisation *from the coreboot side*. In this context, that refers to
any initialisation handled on the main CPU, to bring up the machine for code
execution.
The boot firmware is not the *only* software present in any machine, and there
are some contexts that must be understood to see the bigger picture.
The reason this distinction matters (referring specifically to coreboot's side The reason this distinction matters (referring specifically to coreboot's side
of the initialisation) will become clearer, in the following sections: of the initialisation) will become clearer, in the following sections:
@ -123,13 +109,6 @@ In a *descriptor* configuration, the flash is divided into regions such as:
a hard drive. What's important is that the flash IC is *divided* into such a hard drive. What's important is that the flash IC is *divided* into such
regions, where each region is intended for a specific purpose. regions, where each region is intended for a specific purpose.
On some newer descriptor-based Intel platforms, there are more regions than
this. In some cases, the *[Embedded
Controller](faq.md#ec-embedded-controller-firmware)* (EC) firmware may also
be in its own region of the boot flash; at least for the time being, this is
not the case on any hardware that Libreboot supports (instead, it is stored
on a separate IC).
The contents of the *descriptor* and *GbE* regions are described by Intel The contents of the *descriptor* and *GbE* regions are described by Intel
datasheets, but those datasheets often contain *reserved* sections where datasheets, but those datasheets often contain *reserved* sections where
parts are left undocumented. Reverse engineering efforts over the years have parts are left undocumented. Reverse engineering efforts over the years have
@ -138,74 +117,37 @@ documented some of these blank spots.
Libreboot does *not* distribute Intel ME images Libreboot does *not* distribute Intel ME images
----------------------------------------------- -----------------------------------------------
The ME contains many modules within itself, and one of these modules is the
BringUp code. This BringUp code is the ME's *own* initialisation firmware,
analogous to coreboot. By that very same analogy, the other modules of
Intel ME (such as the ME kernel) are similar (conceptually) to
a *coreboot payload*.
Thus, a *neutered ME* setup is, on the intel ME coprocessor, analogous to
running coreboot without a payload. In this state, the ME initialises itself
ready to run code, but then *doesn't actually run code*. It is thus benign,
both from a security- and freedom-minded point of view. In other words, the ME
is *disabled*.
Libreboot does *not* distribute the Intel ME firmware in any way, whether in Libreboot does *not* distribute the Intel ME firmware in any way, whether in
the Git repository or in releases. Where it is needed, Libreboot provides the Git repository or in releases. Where it is needed, Libreboot provides
scripts that automatically fetch and install it, in a *neutered* state by scripts that automatically fetch and install it, in a *neutered* (disabled)
running the `me_cleaner` program, which you can learn about here: state by running the `me_cleaner` program. This is completely automated.
Please read:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F> <https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
This is completely automated. If you're compiling ROM images from `lbmk.git`, The *BringUp* code of Intel ME is all that remains, in Libreboot configurations.
libreboot's automated build system, the ME firmware will be downloaded, ME BringUp (BUP) is analogous to coreboot, providing initialisation for the
neutered with `me_cleaner` and inserted into the final ROM image automatically. ME itself; by that same analogy, the way Libreboot configures it is similar to
running *coreboot* without a payload. The ME is initialised, to a state where
it can run code, but then it *doesn't actually run code*. It is thus *disabled*.
*Released* ROM images, provided pre-compiled, omit the Intel ME firmware. On In other words, a *neutered* Intel ME setup is completely benign, both from a
platforms that require it, the *same* scripts that insert it during the build software freedom and security perspective. It becomes a useless, unused
process can *also* run post-build, reinserting Intel ME into the boot ROM. This processor, that most people in the real world will ever want to use anyway.
is due to licensing issues surrounding the distribution of Intel ME images. With this perspective, we see that Intel ME is now entirely inconsequential
to the average user.
The Libreboot build system fetches it directly from the vendor for a given *Released* Libreboot ROM images, provided pre-compiled, do *not* include the
machine or set of machines (as an example, Lenovo provides images for several ME firmware at all; they are scrubbed, by automated release scripts when they're
ThinkPad machines). This ensures that each user gets the exactly same preparing a release. If you're building from source, the Libreboot build system
configuration (the other alternative is to extract Intel ME firmware from the will automatically download it (from the vendor), neuter it and then insert it;
original vendor image, in the ME region of the flash IC). on release ROMs, the same scripts used by the build systems can (must) be run
manually, accomplishing the same result after the fact. Please read:
You can learn more about this on the following page:
[docs/install/ivy_has_common.md](docs/install/ivy_has_common.md) [docs/install/ivy_has_common.md](docs/install/ivy_has_common.md)
The ME firmware is *required* on almost all Intel platforms, or the machine The ME firmware is *required* on almost all Intel platforms, or the machine
will turn *off* after 30 minutes. In the neutered setup, the BringUp code of will turn *off* after 30 minutes (or it will not boot, if the ME also controls
Intel's ME will disable that 30 minute reset time, allowing you to use your whether the CPU comes out of reset).
computer normally even though the ME is *not* running anything after that.
Neutered ME really is disabled
------------------------------
Consider this: if the ME is only doing it's own BringUp, but then not
running anything, is it really anything more than a slight drain on your
battery life? In the neutered state, Intel ME is just an inactive computer
on your mainboard, one that does nothing, that you don't need and that you
will never use. Therefore, it might be considered benign from both a software
freedom perspective and a security perspective, and such is the view taken by
the Libreboot project.
If these assumptions are held, and you agreed with Libreboot's article about
microcode as linked above, and you considered the *fact* that (at least as of
now) Libreboot is capable of purely libre initialisation within coreboot, then
we can reasonably assert that Libreboot provides a decent level of software
freedom. This, in spite of how some may otherwise feel if they *don't* have
such perspective.
So, even though the remaining BringUp code for Intel ME *is* proprietary,
and cannot be modified due to cryptographic signature verification by the
hardware, it's software for a device you'll never want to actually use in
the real world, so if it's *not doing anything* in the neutered state, then
it can be ignored in practise. This depends on your point of view, and some
people may take a more dogmatic approach than this. The Libreboot project
considers neutered ME setups to be acceptable, both from a security perspective
and software freedom perspective.
More about Intel ME removal/disabling More about Intel ME removal/disabling
---------------------------------- ----------------------------------
@ -215,33 +157,38 @@ full use of the machine, on GM45 platforms with ICH9M southbridge. These are
laptops: ThinkPad X200/T400/T500/W500 and so on of that generation. See: laptops: ThinkPad X200/T400/T500/W500 and so on of that generation. See:
[docs/install/ich9utils.md](docs/install/ich9utils.md) [docs/install/ich9utils.md](docs/install/ich9utils.md)
On newer platforms, `me_cleaner` is used. You can read about there here: The `ich9utils` software is provided by Libreboot. The `ich9gen` utility was
specifically written by Leah Rowe, in 2014 and improved incrementally since.
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F> On newer platforms as alluded to above, `me_cleaner` is used instead.
Notes about specific types of blobs
===================================
VGA option ROMs VGA option ROMs
============ ---------------
*Native* video initialisation is supported and *enabled*, for all supported *Native* video initialisation is supported and *enabled*, for all supported
Intel platforms that have it. The source code is provided by coreboot, under Intel platforms that have it. The source code is provided by coreboot, under
free license. free license.
On *some* machines, dual graphics is possible. For example, certain ThinkPad In some cases, a laptop may have a graphics chip that is unsupported by
T440p mainboards come with both an Intel and an Nvidia GPU, where you can coreboot. In this situation, a binary blob called a *VGA Option ROM* must be
either use *both* or just the Intel one; to use the Nvidia GPU, a binary blob used. Libreboot has *experimental* support for Nvidia GPU models of the Dell
is required that Libreboot does not provide (nor will provide), instead opting Latitude E6400, in an experimental branch where the build system automatically
to enable only the *Intel* GPU (where libre initialisation code is available downloads the VGA ROM for it. This is currently *not* present in releases, or
in coreboot). In most T440p mainboards, *only* the Intel GPU is physically in the stable branch of `lbmk`.
present.
On some ThinkPad T400, W500 and T500 mainboards, an ATI and Intel GPU is In other instances, a machine may have *two* graphics devices, where one has
present, and you can use either or. Once again, Libreboot *only* supports the native (free/libre) initialisation provided by coreboot. In these situations,
Intel GPU, where coreboot has libre initialisation code. it is possible to insert a VGA ROM for the other one; Libreboot currently lacks
documentation for this, but it has been tested. Example: Dual Intel/Nvidia
graphics on some ivybridge or haswell thinkpads.
This is an example of the nuanced nature in Libreboot's policy. Libreboot For *add-on* GPUs, SeaBIOS (payload) can typically scan a VGA ROM present on
*could* provide such blobs, with the justification that they are *needed* to the card and execute it. This has been tested on certain desktop mainboards
use those extra processors. However, in practise, the machines are completely that Libreboot supports, and works just fine; Libreboot does not need to handle
useable with just Intel graphics for which source code is available. these blobs at all.
Libreboot's default is *always* freedom, when feasible in practise. Users who Libreboot's default is *always* freedom, when feasible in practise. Users who
wish to have use of these additional GPUs, on such hardware, must take stock wish to have use of these additional GPUs, on such hardware, must take stock
@ -270,15 +217,12 @@ ARM platforms (chromebooks)
Mostly blobless, except for the requirement on `daisy` and `peach` mainboards Mostly blobless, except for the requirement on `daisy` and `peach` mainboards
to include BL1 bootloader blobs. These are: to include BL1 bootloader blobs. These are:
* HP Chromebook 11 G1 (daisy-spring) * HP Chromebook 11 G1 (daisy-spring) **(board removed from Libreboot, due to
* Samsung Chromebook XE303 (daisy-snow) issues (will be re-added at a later date)**
* Samsung Chromebook 2 13” (peach-pi) * Samsung Chromebook XE303 (daisy-snow) **(ditto)**
* Samsung Chromebook 2 11” (peach-pit) * Samsung Chromebook 2 13” (peach-pi) **(ditto)**
* Samsung Chromebook 2 11” (peach-pit) **(ditto)**
Libreboot *currently* does not accomodate these blobs at all, and this is * nyan-* chromebooks also temporarily removed, but are blobless in Libreboot
considered to be a *bug*; such is documented on the hardware compatibility
page. They can be added manually by the user, but documentation for this is
currently lacking in the Libreboot website.
List of blobs needed, specifically for each board List of blobs needed, specifically for each board
================================================= =================================================
@ -295,26 +239,31 @@ Here is a list, *for each* board, of those blobs:
Intel/x86 Intel/x86
--------- ---------
### Intel ME:
Neutered ME required on these targets: `t420_8mb`, `t420s_8mb`, `t430_12mb`, Neutered ME required on these targets: `t420_8mb`, `t420s_8mb`, `t430_12mb`,
`t440p_12mb`, `t440pmrc_12mb`, `t520_8mb`, `t530_12mb`, `w530_12mb`, `t440p_12mb`, `t440pmrc_12mb`, `t520_8mb`, `t530_12mb`, `w530_12mb`,
`w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`, `w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`,
`x230edp_12mb`, `x230t_12mb`, `x230t_16mb`, `hp8200sff`, `hp2560p_8mb` `x230edp_12mb`, `x230t_12mb`, `x230t_16mb`, `hp8200sff`, `hp2560p_8mb`,
and `hp9470m_16mb`. `hp2570p_16mb`, `hp8300usdt_16mb` and `hp9470m_16mb`.
As stated, Libreboot provides this in a state where the ME is no longer a As stated, Libreboot provides this in a state where the ME is no longer a
threat to security. It initialises itself, but then does nothing, so it's threat to security. It initialises itself, but then does nothing, so it's
disabled. This is done using `me_cleaner`. See: disabled. This is done using `me_cleaner`. See:
<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F> <https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
KBC1126 EC firmware on `hp9470m_16mb` and `hp9470m_16mb` - on HP laptops, EC ### KBC1126 EC firmware (HP laptops):
firmware is inserted into main boot flash, rather than being on a separate IC.
This is *better* because libre replacements would be more easy to install in EC firmware is inserted into main boot flash, rather than being on a separate
IC. This is *better* because libre replacements would be more easy to install in
the future, and reverse engineering is made much easier by it. Libreboot's the future, and reverse engineering is made much easier by it. Libreboot's
build system handles such firmware in `blobutil`, automatically downloading build system handles such firmware in `blobutil`, automatically downloading
it during the build process. Libreboot 20230423 onwards does scrub EC firmware it during the build process. Libreboot 20230423 onwards does scrub EC firmware
and provide functionality in `blobutil` insert, to insert them with `cbfstool` and provide functionality in `blobutil` insert, to insert them with `cbfstool`
at the correct offset as defined by coreboot config for each board. at the correct offset as defined by coreboot config for each board.
### CPU microcode:
*Microcode* updates for CPU provided on *all* x86 platforms, by default. Not *Microcode* updates for CPU provided on *all* x86 platforms, by default. Not
technically required, but highly recommended. To remove, do: technically required, but highly recommended. To remove, do:
@ -332,6 +281,8 @@ CPU microcode blobs included by default, on all x86 boards. While not needed
in most cases, their use is highly recommended. For reasons why, see: in most cases, their use is highly recommended. For reasons why, see:
[news/policy.md#more-detailed-insight-about-microcode](news/policy.md#more-detailed-insight-about-microcode) [news/policy.md#more-detailed-insight-about-microcode](news/policy.md#more-detailed-insight-about-microcode)
### Intel Flash Descriptor (IFD):
Intel Flash Descriptors are provided as blobs on some boards, but these are Intel Flash Descriptors are provided as blobs on some boards, but these are
not *software* blobs. They are configurations provided in a binary format, not *software* blobs. They are configurations provided in a binary format,
fully readable by libre software. For example: fully readable by libre software. For example:
@ -353,15 +304,23 @@ Intel GbE NVM config (configuration data, binary-encoded, for gigabit NIC):
ARM/chromebooks ARM/chromebooks
--------------- ---------------
### BL1 bootloader (peach/daisy):
BL1 bootloader needed on: `daisy_snow`, `daisy_spring` and `peach_pit`. BL1 bootloader needed on: `daisy_snow`, `daisy_spring` and `peach_pit`.
These boards are *currently* not present. They were removed from Libreboot,
because the build system does not yet auto-insert the BL1 blobs. The boards
are otherwise believed to work, using Alper's port of U-Boot in Libreboot.
Conclusion Conclusion
========== ==========
From the above, you can see that Libreboot really *does* implement a *binary From the above, you can see that Libreboot really *does* implement a *binary
blobs reduction policy*, with the emphasis on *reduction* being most critical. blobs reduction policy*, with the emphasis on *reduction* being most critical.
It can be asserted that Libreboot does in fact provide a reasonable level of
*software freedom*, on all boards.
Libreboot *could* add a lot of blobs for various platforms, to enable various Libreboot *could* add a lot more blobs for various platforms, to enable various
extra features, that it instead avoids adding, precisely because the *purpose* extra features, that it instead avoids adding, precisely because the *purpose*
of the Libreboot project is to promote *libre* software and *minimise* the of the Libreboot project is to promote *libre* software and *minimise* the
power that proprietary software developers have over users. power that proprietary software developers have over users.