Binary situation

From coreboot
Revision as of 15:36, 26 March 2014 by MrNuke (talk | contribs) (ISA vs non-ISA blobs)
Jump to: navigation, search

The wiki is being retired!

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, recent 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" 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 and can access the networking adapters in a way transparent to the OS (separate MAC and IP).
  • Panic level: medium VGABIOS: 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. Until then you can at least 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. Check http://inertiawar.com/microcode/ for details.
  • Panic level: medium-high Gigabit Ethernet Firmware: If your board uses the on-chipset GbE, it requires a small binary (8KB) with unknown content.
  • 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.

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
  • 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. Older microcode described http://www.securiteam.com/securityreviews/5FP0M1PDFO.html
  • 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 Altera LM32 CPU.

In theory it might be possible to successfully boot an AMD board without all these binaries, with potentially reduced capabilities (no NIC, USB3, fan control)

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

Reasonably 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

References