BIOS Freedom Status as of November 2014

About
Latest Posts

Todd Weaver

Founder and CEO
PGP Fingerprint: B8CA ACEA D949 30F1 23C4 642C 23CF 2E3D 2545 14F7

Latest posts by Todd Weaver (see all)

Hardware Encrypted COMSEC Bundle by Purism - April 29, 2024
Purism Differentiator Series, Part 14: Surveillance Capitalism - April 23, 2024
Purism Differentiator Series, Part 13: Modularity & Right to Repair - April 23, 2024

Steps to free the BIOS:

Fuse CPU to allow unsigned BIOS binaries [DONE!]
Free the FSP/ME
Release a coreboot/libreboot for the Librem 15

The BIOS on the Librem 15 laptop currently uses an Intel binary blob, called FSP. We are working to release this under a free license. The current status of the BIOS freedom is kept here.

Binary Blob Situation

An Intel laptop design using coreboot/libreboot would need the following blobs freed:

Note: Intel at IDF14 suggested they might be willing to share some of the needed information for this effort.

Intel FSP previous known as “Intel Memory Reference Code” composed of several sub-programs (DRAM, PCH, SMC, and USB init)
Microcode updates
Embedded Controller (EC) / System Management Controller (SMC)
Management Engine (ME)

Intel is one of the largest semiconductor manufacturers, so they tend to take a slightly different approach for many of their designs. This section details efforts to build an FSF-endorsed laptop around an Intel CPU.

Intel Initial Chip Selections

The laptop design will probably involve making the right choices for the following chips as well as others:

Intel CPU that does not require microcode updates
Chipset (on Intel it’s called a Platform Controller Hub), example: “Intel X99 PCH”
Embedded Controller
Super I/O
BIOS flash chip (8 Megabytes which is 64 Megabits should be just fine)

Embedded Controller (EC) / System Management Controller

The EC/SMC controls what happens when the system is powered on and powered off. Example: when the user presses the power button to turn the system on.
In a laptop, the EC also handles signaling to/from the laptop battery.
Most of the time the hardware manufacturer who designs the board provides the EC pre-programmed.
The EC is central to functions like power on/off, suspend, and hibernate – so the hardware manufacturer must provide the necessary information for ACPI tables.

Microcode Updates

Neither Intel (nor AMD) allow third-party microcode updates. Both manufacturers use a signature to lock their microcode using a private key held only by the manufacturer.

Both make their CPUs with microcode already loaded at manufacture. This may qualify for the FSF endorsement exception since it is non-writable.

Therefore, it may be possible to purchase a CPU with working microcode. Then, no updates would be required. The CPU must be specified in great detail (e.g. a specific model, stepping, and revision is required) – the manufacturer typically adds microcode changes with each revision of the product.

Intel Firmware Support Package (FSP)

Intel bundles many blobs into a single package called an FSP. Coreboot/Libreboot can use Intel’s FSP but coreboot/libreboot does not provide the information on how to separate the FSP into its individual blobs.

Once the FSP has been analyzed, the list of Intel blobs starts to look similar to the list of AMD blobs:

Intel memory controller initialization source code is not available. The FSP has x86 binary code for this. Required for boot and FSF endorsement.
XHCI (USB 3) – ignore. Use a blob-free one like the PLX USB 3382.
AHCI (SATA) firmware. Intel Rapid Storage Technology adds a small solid-state drive (SSD) to a larger magnetic hard drive – hidden from the OS. It may be possible to bypass Rapid Storage Technology and initialize the SATA ports without a firmware blob.

Intel Management Engine (ME)

The Management Engine (ME) blob. It is a 5 Megabyte blob inside the mainboard bios and details about it can be found here: http://me.bios.io

The FSP binary is just a rework of the older “MRC” blob. The whole reverse engineered MRC blob for sandybridge/ivybridge boards, it is currently available in the coreboot tree as NORTHBRIDGE_SANDYBRIDGE_NATIVE and NORTHBRIDGE_IVYBRIDGE_NATIVE. However, the ME blob is something completely different and is still required to boot the boards that have MRC reversed engineered on.

The Librem PCH X99 uses it and the board will not boot without the blob. It is far bigger and much more dangerous than the FSP blob. The problem with the Management Engine is deeply rooted: it is a separate microcontroller embedded in the PCH and has a full network software stack, has access to DMA and other nasty things. The firmware is signed by Intel and verified at each boot by the microcontroller, and if the firmware signature fails to verify correctly, the x86 cpu will not be allowed to boot. The bus clocks are actually configured by the ME firmware.

This would not be an issue if the microcontroller was isolated from the Internet, but it has a full network stack and can read your hard drive and memory which poses serious privacy concerns. Even though the ME is part of the platform and cannot be changed by usual methods like flashing a new firmware, it has poor security because it relies on security by obscurity which will eventually be cracked and the worst kind of rootkits could then run on them.

In an ideal world, we would need to bypass the ME firmware completely and load our own free ARC firmware that can initialize the clocks on the board. This is nothing to do with FSP.

To make it easier, we could choose a northbridge that has been already ported from MRC to coreboot, such as the sandybridge/ivybridge northbridge. This way FSP is not needed. But we still can’t see a way to disable the ME, there are people working on it but it’s a very very difficult problem to reverse engineer, because it uses RSA-2048 to secure it.

Intel Notes

TBD, need the complete list of blobs in the FSP and confirmation on Intel’s ability to provide proprietary source code.

Intel VGA BIOS – GPU Firmware

Intel integrated graphics is completely open source – no firmware is required.

Intel CPU Selection

Intel CPUs appear to be practically unusable without a microcode update. On the coreboot mailing list (http://www.coreboot.org/pipermail/coreboot/2013-December/076825.html, slightly abbreviated here) Ron Minnich says:

In the beginning, we had no microcode in coreboot, per the main goal: let linux do it. We just let Linux do the update. Not our problem. At some point, ca. 2005 or so, we had to let the blobs in because many of the new CPUs are *broken* without the microcode update: the microcode that comes embedded in the CPU must be updated or you’ll get some real problems, and possibly not even get through firmware.
So, sure, it’s pure to build without the microcode blob, which means in reality that you’re deciding to use the microcode blob *already embedded in the CPU*. And, on many new CPUs, the one that comes with the CPU has issues that mean you won’t get past DRAM init. And, if you do get past DRAM init and boot, you’ve got a CPU that may have subtle errors and corrupt memory.

We may be able to identify a few Intel CPUs that have no microcode updates – never say never, check in detail. However, the best information indicates that Intel does not ship CPUs with fully working microcode.