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.
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 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.
The laptop design will probably involve making the right choices for the following chips as well as others:
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 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:
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.
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.