Building

A Life Without Vendors Binary Blobs

This blogpost will be about my first steps with coreboot and libreboot and a life with as few proprietary firmware blobs as possible. My main motivation were the latest headlines about fancy firmware things like Intel ME, Computrace and UEFI backdoors. This post is not intended to be about a as much as possible hardened system or about coreboot/libreboot being more secure, but rather to be able to look into every part of software running on that system if you want to.

I first got curious about coreboot and libreboot at the 33C3 (Bootstraping a slightly more secure laptop). Then I searched for some old retired hardware at ERNW which I could flash coreboot to and found an old Thinkpad X61. Finding the X60 as officially supported hardware on the libreboot homepage, I have read through the libreboot and coreboot manuals to learn about the main coreboot part and it’s several payloads.

I also needed to order a X60 mainboard as the X61 chipset is yet unsupported and will probably never be supported, so getting a X60 mainboard was the cheapest ways to revive our old pentest notebook.

What is coreboot?

(open) minimal initialization of the hardware + a small (open) payload to load the operating system

+ open source
+ modifiable to own needs
+ minimizes boot time
+ audit-able
+ some manufacturers even ship their hardware with coreboot

– no precompiled ROM binarys
– limited hardware support depending on mainboard + chipset and CPU
– coreboot also must contain proprietary parts on newer x86 systems and arm systems (eg. for graphics and Intel ME/AMT)
– hardware SPI flasher (beaglebone or Raspberry) needed on most models that ship with vendor bios because of writeprotected SPI flash
– often the hardware needs to be disassembled to begin flashing

What is libreboot then?

A libre version of coreboot with the unfree parts stripped away

+ maximum freedom for supported models
+ precompiled ROM binary’s
= has GRUB as default payload, so no windows support, but linux and BSD are fine (who would want windows on a libre laptop anyway)
– less hardware supported (mostly because of this nasty Intel ME or graphics initialization)

Why I wanted to try coreboot

Mostly because I was annoyed by most vendors buggy bios’es and I did not want to have an Intel ME being present. Luckily the X60 was one of the last models which had a CPU generation that worked without supplied Intel ME or microcode updates (if you won’t need virtualization at least on the X60). The X60 also allows, theoretically, to be flashed directly from the OS, but unfortunately I did not get it sorted out (BUCTS). Also having a fully encrypted laptop without proprietary software gave me a somehow better feeling than having to fully trust my vendor.

First steps:

Having read the libreboot and coreboot wiki, I installed debian and got the libreboot utilities as well as the libreboot binarys. Being inexperienced I somehow misunderstood the wiki and rebooted too soon after flashing the first time. The X60 needs to be flashed twice, because the upper part called bootblock cannot be written, instead a backup copy of the bootblock in lower part needs to be written and swapped as active, so that the other (main) bootblock can be written.

Raspberry Pi attached to the SPI flash

So there I was with a technically dead X60 and a failed flash. Fortunately the coreboot and libreboot community documented manual external flashing quite well and so I grabbed one of the fiddly pomona SOIC-8 clips, my raspberry and some tools and flashed it directly via flashrom. This method unfortunately is often the way to go on newer Thinkpad models with coreboot support, as the Intel ME part in the SPI flash is write protected.

This time everything went well and I was greeted by a GRUB with several option, such as looking for a grub.cfg on a USB device. I think it was never easier to boot from a USB device than now. While installing Parabola (I’m more the arch guy and got to know about parabola while doing research on libreboot) I was also now able to put the whole disk into a LUKS container. So if somebody will ever try to fiddle with the unencrypted boot code/partition, it won’t be possible because it simply does not exist on disk.

The Main goal of not using or having to use binary blobs from vendors was now achieved and besides other internal firmware of the soundcard or the embedded controller that controls the fan I’m now able to look into every bit of code on the device.

A followup will involve different payloads like SeaBios or Tiano Core (UEFI) to be tested, maybe I can get even more from this old piece of hardware!

So look out for my next blog post about my journey into coreboot! -Jann

Leave a Reply

Your email address will not be published. Required fields are marked *