If one wishes to build an x86 server or workstation that is as de-blobbed and libre as possible, then the best one can do at this time is to use one of the fully free GNU/Linux distributions (gNewSense, Trisquel, etc) for the operating system and Coreboot for the BIOS firmware. Or so I thought until I read this remark:

At this point, the Google Chromebooks are the only commercially available computers shipping Coreboot by default (although blobbed, because Intel doesn't want to release source code for their microcodes). This is not ideal, I know, but there isn't better alternative if you want to use recent hardware (maybe we should crowdfund a Coreboot-libre spin off, that will focus primarily on providing fully libre BIOS images for Chromebook devices, like Replicant).

So apparently, just as there are non-fully free GNU/Linux distributions, there apparently are non-fully free Coreboot payloads. I should at this point admit that my understanding of Coreboot is minimal.

I would like to know:

  1. When choosing a motherboard, how can I find out which payload(s) are compatible (or vice versa)?
  2. Having done this, how can I tell which payloads are entirely libre?
  3. Have I have got hold of the wrong end of a stick anywhere in the foregoing?

Payloads are generally hardware independent (but there may be bugs lurking). Payloads typically aren't the problem when it comes to software freedom.

You pick them by your needs: If you want to boot a "normal" PC operating system, SeaBIOS is the easiest way to go, since it implements the interfaces that they all expect. If you have any special needs, the other payloads might be closer to what you need, or you can build your own.

There are two "freedom" issues in coreboot itself:

  1. Intel is uncooperative in the free firmware space. Google worked around that by creating an independent binary from Intel's code and then making coreboot work with that. Intel now followed suit and provides such a binary themselves (see http://www.intel.com/fsp). The above quote is misleading: The problem isn't microcode, it's x86 binaries for RAM initalization and firmware for the Management Engine, a companion processor without which the system isn't really functional except by employing a hardware hack (which reduces power management capabilities).

  2. Hardware requires all kinds of additional code or data for initialization. This can be microcode updates for the CPU; firmware for additional microcontrollers, some of which are integrated in the chipsets these days; tables for board specific information like calibration data.

You can bypass some of these binaries and the system will continue to boot (eg. some CPU microcode updates); for others, the absense will lead to reduced functionality, such as no XHCI (and thus USB3) on AMD chipsets without the XHCI firmware; and some binaries will lead to an unbootable system if left out, like the Management Engine on Intel chipsets or CPU microcode updates on some CPUs that come with such faulty microcode that they don't even get through the boot process.

coreboot has a "blobs" repository to keep those things separate, but microcode and some other minor binaries reside in the main repository for historical reasons. There are plans to change that, which are currently discussed at http://www.coreboot.org/pipermail/coreboot/2013-December/076822.html.

However, the likely result is that you'll be forced to use the blobs repository to get usable builds, since some of these binaries really are mandantory on today's hardware.

I found AMD more cooperative, and their binaries less intrusive in the system than what Intel does (and except for microcode updates they're typically unsigned, so with enough time, they could be reverse engineered - but don't wait for it). But they're still miles away from the ideals promoted by Trisquel etc.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy