A few days ago, I got to experience the efforts of a culmination of free software supporters; from Purism team members, ME hackers, coreboot developers, and a lot of other individuals. I am very pleased to run a Librem 13 with coreboot, running a neutralized Intel Management Engine, and no microcode update. I used that setup to type this blog post!

Coreboot is fantastic, stable, secure, fast, and free software. So I am very excited to reach one of our milestones with the Librem 13 toward our goal of digging deeper and deeper, freeing more and more of our high-end hardware. If you care to read more on our approach, business model, and vision, it would probably provide some context as to where we are and how far we plan to go.

A neutralized Intel Management Engine

The Intel Management Engine (not to be confused with the Intel AMT–which we already avoid), shortened to Intel ME, is a very large binary (1.5MB) included within Coreboot to bring-up post-2008 era CPUs. We have known it was possible and have stated that we plan to remove this binary, often considered the nastiest of binaries compared to memory init, ref-code, or vbios. Based off the tremendous work from me_cleaner, we can safely gut over 90% of the Intel ME, removing all the backdoor networking stack, leaving only the very small section (120k) to initialize and configure the hardware.

Testing out usage without microcode updates

There are plenty of debates over including microcode updates or not, with the philosophical discussion ranging from “The original microcode is already trusted from the CPU vendor when you first get the CPU, so why not apply the microcode updates?”, to “No microcode update should be applied because it is loaded on the CPU via a flashing utility in software”.

Whatever side of the fence you’re on, we wanted to give users the control to include or not include the microcode updates, and as such worked to source CPUs that had a low stepping so the microcode updates were not completely insurmountable, and at least possible to run without these updates. I am typing this now on a Librem 13 that has no microcode update applied, and we will allow for users to decide a no-microcode-updates option (with the risks that it may carry in hard-lock-ups or inaccurate floating point calculations) or a microcode option (with the risks that it may carry in bit flips provided from the CPU vendor). I personally have rolled back in the microcode update, because I saw odd system lock-up behavior within 24 hours of operation at random times. With the microcode rolled back in, I am back to a stable never-locking-up behavior, as I would expect from a Librem laptop.