Brendan Horan Avatar

Overview

This guide will be separated into two posts due to its length.
This is part one and will focus on the why and requirements.

I use GPG and Yubikey's a lot!
However, have we ever stopped to think about the machine that creates the private keys/secure matter? Using a VM or boot into a LiveCD should be enough?
Sadly, no.
This two part post takes a pretty extreme standard, but one that is achievable by most people.
Nothing is perfect and everything has trade-offs so sit back, take a read the problem space is quite interesting and can easily send you down a rabbit hole.

This post details my quest to create a pure/libre machine with no known back-doors.
I plan to use this machine as a secure system to create my keys/secure matter.

So to start off, we need to understand what makes a normal machine insecure by this standard.
Let's start with the Intel Management Engine.

Intel ME

So, why did I buy an old Core2duo laptop, I hear you asking?
The Intel GM45/ICH9M combination was the last possible Intel CPU to have the Intel Management Engine fully disabled. Why is that a big deal?

Traditionally, CPU's would define protection rings, ring 0 been the most privileged and ring 3 been the least privileged. Things like kernel I/O would be in ring 0 and ring 3 would be use mode applications.

So what level does the Intel ME run at?
Not ring 0, but ring -3, wait what ? Negative rings?

Yep, the intel ME is active even when your machine is asleep(S3 state) hence the name of the ring level.
So your machine is asleep, but someone/something can still install a rootkit?
How can this be? If the CPU is asleep?
That is because the intel ME is a separate CPU inside your chipsets, originally was part of intel network control chipsets.
Intel ME contains its own MAC and IP stack for out of bands management.

It is watching you while you sleep/your machine is off.
Ouch!

What can we do about it?
In terms of a modern machine, limited can be done. Vendors like Purism and System76 provide machines with a Coreboot distribution instead of the UEFI/BIOS. While that helps it is not a pure libre bootloader and still contains binary blobs, again this is almost impossible to avoid on modern x86 hardware.

Thus, we need to go back in time to when the Intel ME could be fully disabled without crippling the machine or losing functionality.

I have spoken in depth about Intel and the ME, but AMD has similar issues with its PSP/Secure Technology (Platform Security Processor), however that is out of scope for this post.

Libreboot

What and why?
Libreboot is a Coreboot distribution with a focus on blob-free booting. Obviously, this reduces the machines that the Libreboot distribution supports vs vanilla Coreboot. That is expected and okay.
Much in the same way Debian ships no binary blobs out of the box, you can add them if needed, but they are not there by default. Libreboot gives us that same level of freedom but right down to the hardware initialisation stage.

So, let's go get a Core2Duo laptop!

Hardware

Libreboot supports quite a few machines. However, for my needs, the Dell E6400 stands out. There are two main types of the E6400, one with a Nvida GPU and one with an integrated Intel GPU only.
At all costs avoid the NVIDIA GPU, it requires binary blobs and has a tendency to overheat the machine!

Why the Dell?

  • Cheep, easy to get second hand.
  • Supports 8gb ram.
  • Has a decent keyboard and track point mouse.
  • Can be flashed without an external SPI based flasher.

It is pretty much a cheap, ugly and heavy ThinkPad.

It has a few downsides however:

  • Max 8 GB ram, 2x SO-DIMM slots – PC2-6400 DDR2-800Mhz. 4 GB max per slot.
  • SATA 2 only, if you want a new SSD, it must support fallback to SATA2, SATA3 drives will not be detected.

I am using a Kingston 480GB 2.5in A400 SSD. Model Number SA400S37/480G, cheep and supports SATA2.
4 GB DDR2 DIMM's are not so common, but if you wait you can find some at a decent price.
You also could opt for less RAM as our OS install will be quite lightweight too.

If you get one of these machines, and you open the bottom part of the case, and you see a sticker with 3 ME attached, even better.
This configuration was sold via Dell with the Intel ME disabled already, however you should still install Libreboot.

Preparation steps

Dell BIOS

While Libreboot will replace the BIOS, Dell like other manufactures would bundle updates to other parts of the system in their BIOS updates. Thus, it is wise to update to the latest Dell BIOS before flashing Libreboot.

Prerequisites

You are going to need three things:

First download the BIOS file. Details are:
Version A34, release date 16 Jul 2013, Filename E6400A34.exe.

Next download FreeDOS, for this task I used FreeDOS 1.3 LiteUSB (FD13-LiteUSB.zip) Once both items are downloaded, unzip Freedos and write it to a USB stick, example:
dd if=FD13LITE.img of=/dev/sda bs=4M.
Once that is done, mount the primary dos partition and copy across the E6400A34.exe file to the USB stick.
Boot the Dell laptop off this USB stick into FreeDOS and run the E6400A34.exe application, it should start the BIOS update process and reboot when done. In my case, the new BIOS proved keyboard firmware updates.

There is no need to worry about the BIOS settings, just make sure you can boot from USB.

Live media

Next we need to download a live media so that we can boot the machine, install any tool-chains we need and build Libreboot.

I will be using Debian running in-ram to build Libreboot.
I make use of the hybrid media since it can be written to USB or DVD media. For this task, I will be using a USB stick with debian-live-12.1.0-amd64-xfce.iso.
The live environment gives us a full desktop to work with, however you could do all the steps with just a CLI console as well.

A key reason why I have selected Debian is they do not include “Non-free Firmware blobs” by default.

Debian has a decent FAQ if you require help writing the images to a bootable media.

Changing kernel parameters on boot

For all the following steps, we need to boot the live media with an extra kernel parameter.
The parameter iomem=relaxed will disable memory protection in the OS, allowing us read and write access to the device /dev/mem this is needed for the flash unlocking utility later on.

To edit the boot menu, hit TAB when you see the GRUB boot screen, then add iomem=relaxed to the Grub append line.
Once booted, check that the setting has been applied by running the command:
cat /proc/cmdline and check that iomem=relaxed is present.

Building Libreboot

Boot the Debian live image, ensure your machine has internet access for the next few steps.

Development dependencies

Root user or sudo steps

Now let's ensure we are all updated (run via sudo or a root account):

apt-get update && apt-get upgrade -yy

Next up, install the Libreboot build dependencies. I've taken thepkglist from this file and run it via (run via sudo or a root account):

apt-get install -yy \
flashrom wget git uuid-dev nasm build-essential sharutils curl parted e2fsprogs unzip \
pkg-config gcc-arm-linux-gnueabi \
build-essential python3 \
build-essential perl python3-setuptools libncurses5-dev doxygen iasl gdb flex \
bison build-essential git libssl-dev gnat python-is-python3 \
fonts-unifont libopts25 libselinux1-dev autogen m4 autoconf help2man \
libopts25-dev libfont-freetype-perl automake autotools-dev build-essential bison \
flex libfuse-dev liblzma-dev gawk libdevmapper-dev libtool libfreetype6-dev \
gettext unifont bc bison build-essential device-tree-compiler efitools flex \
libfdt-dev liblz4-tool libgnutls28-dev libncurses-dev libpython3-dev libsdl2-dev \
libssl-dev lz4 lzma lzma-alone openssl pkg-config python3 python3-distutils \
python3-pkg-resources python3-pycryptodome python3-pyelftools swig uuid-dev \
build-essential libpci-dev pciutils zlib1g-dev libftdi-dev build-essential \
libusb-1.0-0-dev libusb-1.0 libusb-1.0-0-dev libusb-dev cmake \
innoextract p7zip p7zip-full unar

Once that is done we need to add a non-root user, this can be your user account, the live boot user or anything.
I like to name this account as build (command run via sudo or a root account):

adduser build

Accept all the defaults and move on, this is really only needed if you are running as root, since Libreboot will not allow the root user to build ROMs. So any user account except root is fine.

Non-root user steps

The following steps are executed as the build user.

First clone the Libreboot repository:

git clone https://codeberg.org/libreboot/lbmk

At the time of wring this article, the git commit I was working from is:

8fc5f6ed53a9ad6b2270cf85a305300cedf1b7f2

Libreboot is pretty active, so things change, but you could always go back to this commit and follow this guide.

Blobs

Since the E6400 requires no binary blobs to be extracted, we can move on to the build stage.
The E6400 can use all libre initialisation code in Coreboot to bring online all hardware.

NOTE:
This is only valid for the E6400 without an NVIDIA GPU, The machine with this GPU is out of scope in this post but covered by Libreboot's page on the E6400.

Microcode

What about Microcode, I hear you ask, this is a binary blob!
You are right, it is a blob, and this is where Libreboot takes a pragmatic approach.

Microcode is very limited in what it can do/patch at a hardware level, I agree with Libreboot's policy around Microcode. Microcode are like security patches, not using them is irresponsible.

Libreboot has a detailed write-up of why Microcode is not an issue or security concern.

If you would like to understand how Microcode works at a CPU register level, take a read of Ken Shirriff's blog post on how the microcode engine works.

From now on, ensure you are inside the lbmk directory and as the build user.

Git config

Libreboot expects a few settings for git to be configured, otherwise the build script will emit errors. So set your username and an email address in the git config:

git config --global user.name build
git config --global user.email build@localhost

Build ROM's

The ./build script will need to download a bunch of dependencies the first time the script runs.

To build the ROM for the target e6400 run the following:

./build boot roms e6400_4mb

ROM files will be placed under the bin/ directory.

This will build two ROM files, one that uses the Coreboot Frame Buffer and one that uses Text mode. The ROM files will have the one of following components in their filename:

  • libgfxinit corebootfb
  • libgfxinit txtmode

Corebootfb– is the high resolution frame-buffer mode.
Txtmode -- is a text mode only version.

I will be making use of the corebootfb version to give me high resolution support for SeaBIOS.

If you would like to configure custom options for the ROM build, the two main files to look at are: Libreboot configuration:
config/coreboot/e6400_4mb/target.cfg And: Coreboot configuration: config/coreboot/e6400_4mb/config/libgfxinit_corebootfb

NOTE!
Keep in mind, you really need to understand the hardware you are working with and all of its quirks.
For example, the E6400 uses SeaBIOS vs pure GRUB as a payload, why?

The GRUB payload has an issue with the way the embedded controller (EC) that implements/handles the keyboard, thus causing the GRUB payload to be unusable.

So while GRUB might seem like a better choice than SeaBIOS, you will end up causing yourself issues, since you don't fully understand all the hardware quirks.

Messing with Coreboot config requires you to understand all the hardware, its errata and how they affect each component in the system.

I do not have any need to edit the defaults for Libreboot and Coreboot.

Part two

In the next post, we will discover how to unlock the flash and flash Libreboot to the machine.

References