Binary situation

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.

Intel

On Intel based chipsets (since Intel 5 Series) the following binary components persist:

• Panic level: 9000+ Management Engine firmware: The management engine is a separate CPU that does various management tasks and needs its own firmware. This firmware exists in a 1.5MB and a 5MB version, where the latter provides the "Intel AMT/vPro" functions (ie. remote access, "anti-theft", ...). Probably signed with an Intel key. It's unlikely that this is ever replaced by something open source. Firmware that runs on an ARC core inside the chipset. It runs entirely out-of-band with the main CPU. It has DMA access to the entire system memory (can also override IOMMU) and can access the networking adapters in a way transparent to the OS (separate MAC and IP). (can be removed on GM45. See ich9gen notes on the X200 page or on libreboot.org)

• Panic level: 8999 Memory Reference Code: (Sandybridge and newer). This is code that runs on the CPU and initializes RAM. Can be reverse engineered with enough persistence, but not done so far. The "Memory Reference Code", initializes memory and USB power states (other functions are yet unknown). It is provided by Google, and is wrapper for Intel PEI modules. (see Intel_Native_Raminit for sandy/ivybridge native coreboot raminit)

• Panic level: medium VGA BIOS: Runs on the CPU. Unless you can live with staying in the dark until Linux takes over, you'll need this. Luckily there's work in progress to replace it with open source code on many systems (some systems already have a free replacement. 'native graphics initialization'). Until then you can at least somehow contain it by emulation (see YABEL).

• Panic level: small CPU microcode: Intel provides this as redistributable binary, the format is partially reverse engineered, it's covered by a 2048b RSA signature. Unlikely that it can be replaced. Depending on the CPU (incl. its stepping) it might be possible to get by without it if the CPU has no security related or other significant errata. Check http://inertiawar.com/microcode/ for details.

• Panic level: small Gigabit Ethernet Firmware: If your board uses the on-chipset GbE, it requires a small binary (8KB), which contains configuration data (but no executable code) for the onboard ethernet chipset (also contains configuration data for the ME/AMT on some systems). (reverse engineered on GM45. See ich9gen notes on the X200 page or on libreboot.org)

recent AMD

• IMC: An embedded controller of sorts in the southbridge. 8051-based, can probably be reimplemented (partially done, but unpublished) Check the AMD_IMC page. The controller is either enabled by hardware strap option. Or if you provide a firmware, the controller is enabled via soft strapping the chipset. It is 8051 controller.

• XHCI: Controller for USB 3.0 controllers. Analysis has shown that the firmware used in AMD system is most likely Renesas USB 3.0 IP Core. It seems it is V850 compatible controller If not present, USB3 (and related USB ports) won't work. Partial documentation is at AMD_XHCI.

• NIC Firmware: If your board uses the on-chip broadcom NIC, you need this firmware. Luckily few boards do (thanks to Broadcom seemingly having some "interesting" terms and conditions on its use) Check http://review.coreboot.org/#/c/2831/ for partial documentation

• Panic level: small CPU microcode: AMD provides this as redistributable binary, the format is partially reverse engineered, it's covered by a 2048b RSA signature. Unlikely that it can be replaced. Depending on the CPU (incl. its stepping) it might be possible to get by without it if the CPU has no security related or other significant errata. Older microcode described http://www.securiteam.com/securityreviews/5FP0M1PDFO.html

• Panic level: medium-high SMU: Another embedded controller, The SMU seems to be handling PCIe power management stuff in AMD northbridges (from RS880 onwards?) the firmware is loaded during system boot. It is unknown if the firmware has to be loaded. The SMU is most likely LatticeMico32 CPU. See https://github.com/zamaudio/smutool

• VGA BIOS: The VGA BIOS contains bytecode which is motherboard/layout specific. Open source efforts here http://sourceforge.net/projects/openradeonbios/?source=dlp

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

• Panic level: high PSP: The Cortex A8 running trustzone firmware, implemented from family 15h model 60h (Carrizo) and family 16h model 30h (Mullins) and up. It is running Trustonic TEE OS licensed by AMD. PSP Boot ROM runs *before* x86 core. Then non-bootrom PSP parts are stored (zlib-compressed) in the main flash. Bypass mechanism available via strap pin, but dummy and AMD signed bypass binaries needs to be always run. It is expected that newer CPUs will offload part of AGESA to the PSP, making memory init even part of the PSP :(

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.

Classification of blobs

ISA vs non-ISA blobs

We use the term ISA blob (Instruction Set Architecture) to denote a blob which

1. Contains a set of instructions in the main processor's instruction set
2. Those instructions are executed on the main CPU

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.

Axis 1: Essential vs non-essential blobs

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.

Axis 2: Replaceable blobs

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:

1. The hardware is reasonably documented
2. The process of loading the blob is well understood
3. The blob can be loaded without the need to circumvent cryptographic protections

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

Axis 3: Always-on blobs

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.

References

• Brief explanation of what a blob is.
• Brief explanation of "panic level" rating system.