Documentation is now handled by the same processes we use for code: Add something to the Documentation/ directory in the coreboot repo, and it will be rendered to https://doc.coreboot.org/. Contributions welcome!
While we aim for a 100% free boot process, developments (and general unwillingness by some hardware companies to provide specifications) make it hard to achieve.
On Intel based chipsets (since Intel 5 Series) the following binary components persist:
In theory it might be possible to successfully boot an AMD board without all these binaries, with potentially reduced capabilities (no onboard broadcom NIC, USB3, or fan control) Some AMD boards currently have support for fully functional blob free operations (ex: the KGPE-D16).
PSP is AMD's analog of Intel's ME with a few implementation differences, in laymans terms the panic level is the same and it is present on newer AMD processors (see above) including FM2+ and Zen (AM4), it is also present on the die but supposedly not activated on various older models as well.
We use the term ISA blob (Instruction Set Architecture) to denote a blob which
For example, MRC is a blob which contains x86 instructions on some Intel CPUs (x86) to initialize memory. It is considered an ISA blob. A video BIOS is also an ISA blob. On the other hand, CPU microcode is a non-ISA blob as it is not a set of x86 (or ARMv7) instructions, despite it residing in the main CPU.
We consider a blob essential if the machine cannot fulfill its intended purpose without the blob. For example, if memory initialization is done by a blob, then that blob is essential, as the machine will never be able to boot an operating system.
Whether a certain blob is essential or non-essential depends on both the nature of the machine, and the nature of the blob. For example, a VBIOS on a laptop is normally considered essential, as the laptop will be useless without the display. However, if the operating system can initialize the graphics hardware without the VBIOS, then the laptop can be used normally, and the blob is considered non-essential. However, in the case of a headless server, the blob is always non-essential, as the display functionality is neither needed, nor used, regardless of the OS's ability to initialize the graphics hardware.
Blobs for certain subsystems, such as USB 3.0 firmware blobs, are also non-essential, as the machine can function normally without USB 3.0 functionality.
A blob is considered reasonably replaceable if it can be replaced with a free alternative, by community effort, in a reasonable timeframe, with a reasonable amount of effort. For this to be possible, the following conditions must usually be met:
Point (1) ensures that tools, such as compilers, are easily available, and that super-human effort is not required in order to reverse-engineer the blob and understand its function. Point (2) ensures that once a free replacement is available, it can be uploaded to the hardware and executed. Proprietary and undocumented checksumming algorithms, for example, would make the replacement impossible to upload until such algorithm is understood. Also, if the blob is loaded automatically by hardware, the form in which it must be presented to the hardware must be understood and reproducible. Point (3) ensures that any free replacement can be executed without needing approval and/or verification from the hardware manufacturer. This is important in ensuring that the user, not the vendor, controls the hardware.
For example, a video BIOS for a documented GPU is reasonably replaceable. Since a VBIOS usually consists of x86 instructions, compilers are readily available, and the register map is documented, satisfying point (1). Although the structure of a PCI option ROM, and thus a VBIOS is well understood and documented, it is not required, as a VBIOS replacement is usually implemented as native VGA initialization. This satisfies point (2). Point (3) is irrelevant, as the free replacement would be implemented as native coreboot code.
On the other hand, a Management Engine blob is not replaceable as it is cryptographically signed. the hardware will not execute any ME blob which is not signed by the manufacturer (Intel), thus violating point (3).
A blob is considered always-on if the blob continues to be active and capable of execution after the system is brought up. If a blob only runs briefly to initialize a certain component during system bring-up, then that blob is not always-on.
For example ME or USB 3.0 firmwares are always-on, as they operate concurrently with the OS.
Always-on blobs are especially troublesome for platform security because they expose new attack surfaces. For example, arbitrary code execution vulnerabilities have been demonstrated in both ME and SMU. Since the majority of always-on blobs control hardware with DMA access, these vulnerabilities present a hidden risk to system security. Enabling features such as IOMMU may alleviate such risks, but does not eliminate them entirely.