Is hardware the black hole of computing ?

Part II: shedding light on the darkness

Lukas
Linagora Engineering
6 min readSep 14, 2018

--

Hardware: irreducible complexity. Photo by Alexandre Debiève on Unsplash

The problem

As stated in the part 1 of this article, hardware is indeed the black hole of computing today. Unsurprisingly, it is even considered harmful by some. The problem can be summarized in these words:

What can be done to change this situation? How can hardware be made more trustworthy? There are at least two angles to approach the problem:

  • Political answers, which include market or product regulations, dedicated public policies, increased pressure on silicon vendors, etc.
  • Technical answers, which propose ways to mitigate risks in the short-term and offer new ways to build hardware and firmware in the long-term. Risk mitigation is the focus of this current article.

Thanks to LINAGORA, which is currently looking for new talent, for its support and for making this article possible! This opinion piece doesn’t necessarily reflect my employer’s stance on the subject.

Taming the firmware

Closed source components, such as the Unified Extensible Firmware Interface (UEFI), the System Management Mode (SMM), the Intel Management Engine (Intel ME) and the AMD Secure Technology, are tightly integrated with the hardware.

They need to be pruned, and whenever possible, completely removed and replaced with open source alternatives. This is not as easy as a shell command.

The UEFI logo by Mouagip (Public Domain)

The UEFI

Before we look at ways to neutralize the Unified Extensible Firmware Interface (UEFI), let’s define it. As explained by J.B. Crawford, a UEFI computer boots in four phases:

The security phase (SEC) and the Pre-EFI Initialization Stage (PEI) are responsible for low-level operations to prepare the hardware and are usually specific to the hardware they are implemented for. After these two stages, the Driver Execution Environment (DXE) loads various drivers, and then the Boot Device Select (BDS) phase can begin.

You can spot the System Management Mode (SMM) in the bottom-right corner. Contrary to the UEFI, it stays active after the boot process is complete. TianoCore is an open source implementation of the UEFI maintained by Intel, but is unavailable on bare-metal hardware. SeaBIOS is an open implementation of the BIOS. (Illustration is borrowed from BIOS Protection Guidelines. © National Institute of Standards and Technology)
The Coreboot logo by Coreboot.

Silencing the UEFI and the SMM

What are the primary solutions available today to make the early stages of the boot process, the so-called SEC and PEI stages, more flexible and trustworthy?

Coreboot, alas not entirely free but deployed on a vast number of hardware — including almost all Chrome OS devices — and Libreboot, entirely free but available only on a limited number of very old hardware platforms, represent two of the best options.

Coreboot has many advantages over UEFI, including faster boot time and more flexibility.

The process of installing Coreboot requires flashing the actual motherboard with a new firmware, something that is both non-trivial and hardware-specific.

Fortunately, this service is offered by third parties, at least when it comes to Libreboot. Some hardware vendors like Purism offer newer computers with Coreboot pre-installed.

Unfortunately, as of now, the System Management Mode (SMM) cannot be easily removed or replaced and has been included into Coreboot, as it is needed by laptops. However, there are attempts to move it into the kernel.

The LinuxBoot logo by Susanne Nähler from 9elements (CC BY ND 4.0)

Linux under Linux

Coreboot and Libreboot require a payload to continue the boot process and to load specific drivers. In other words, how do we deal with the so-called DXE and BDS stages in the UEFI boot?

What piece of software is open, flexible and compatible with a wide range of hardware?

Originally called NERF (for Non-Extensible Reduced Firmware — a pun directed at the Unified Extensible Firmware Interface (UEFI)), LinuxBoots intent is to replace the aforementioned DXE and BDS stages by — you guessed it — a Linux kernel and an initial ram file system file (initramfs). The initramfs are used to load the root file system in the memory.

Still in its infancy, LinuxBoot is intended for server hardware, with the notable exception of Heads (check out this great guide by Trammel Hudson on how to install Heads on a Laptop, or this transcript of his presentation on LinuxBoot at the Chaos Communication Congress in 2017.)

Where LinuxBoot fits in. LinuxBoot is agnostic,and supports several different initramfs. (© LinuxBoot.org)

With LinuxBoot, Linux takes care of booting Linux. With Coreboot, hardware initialization is more transparent than with the original firmware. (Intel recently made the Firmware Support Package (FSP) license easier to read and to comply with. These open firmware, LinuxBoot and Coreboot, rely on the FSP and are likely to be ported on more hardware thanks to the re-licensing.)

Rocky Raccoon, MINIX’s mascot. (MINIX, CC BY-SA 4.0)

Targeting the Intel ME

What about MINIX, the operating system lurking under Linux inside the Intel ME?

It appears that a kill switch exists, and that is had been put in place to comply with stringent security environments, in particular the NSA High Assurance Platform (HAP).

A Python script aptly named me_cleaner is leveraging this possibility, and can be used to deactivate most of the Intel ME.

Update your peripheral firmware

On Linux, or really any platform for that matter, it is often difficult to patch the firmware located in your hard disk, your Bluetooth dongle and other peripherals.

An initiative by Richard Hughes named the Linux Vendor Firmware Service (LVFS) offers a dedicated software called fwupd which allows Linux users to patch some of the firmware attached to their machine. It offers a place for vendors to send their updated firmware so they can be easily consumed by end-users through the fwupd software. On top of that, the project lists vendors that are willing to send updated firmware, alongside those that aren’t.

The need for starting from scratch

Current attempts to fix firmware are akin to patching a software in production sold by a monopoly which you have to use but cannot know about. This problem should not exist in the first place, and even though it does:

it is not up to customers to fix faulty products.

Common and widely available hardware are flawed beyond repair.

There is a need to build more open platforms from the get-go. How can we go further?

How about building open hardware…

Incidentally, the Open Source Firmware Conference (OSFC) is currently happening in Erlangen, Germany. Have a look at their program to see what is being done now by whom. Hopefully, they will publish transcripts or video recordings of their conferences.

What it takes to make your hardware freer. At the very least one Club Mate. (Photo © Trammel Hudson)

--

--