Todd’s Purism Librem 13 experience with coreboot and a neutralized ME

• About
• Latest Posts

Todd Weaver

Founder and CEO
PGP Fingerprint: B8CA ACEA D949 30F1 23C4 642C 23CF 2E3D 2545 14F7

Latest posts by Todd Weaver (see all)

• Hardware Encrypted COMSEC Bundle by Purism - April 29, 2024
• Purism Differentiator Series, Part 14: Surveillance Capitalism - April 23, 2024
• Purism Differentiator Series, Part 13: Modularity & Right to Repair - April 23, 2024

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.

todd@librem-13:~/proj/coreboot-dev/coreboot/util/cbmem$ sudo ./cbmem -c | egrep -i "coreboot-|purism|librem"
coreboot-4.5-1035-g6a02eeb Mon Feb 20 17:34:53 UTC 2017 romstage starting...
coreboot-4.5-1035-g6a02eeb Mon Feb 20 17:34:53 UTC 2017 ramstage starting...
Root Device (Purism Librem 13)
Found mainboard Purism Librem 13
todd@librem-13:~/proj/coreboot-dev/coreboot/util/cbmem$

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.

todd@librem-13:~/proj/coreboot-dev/coreboot/util/cbmem$ sudo ./cbmem -c | grep ^ME
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Recovery
ME: Current Operation State : Bring up
ME: Current Operation Mode : Normal
ME: Error Code : No Error
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : Waiting for DID BIOS message
ME: HSIO Version : 0 (CRC 0x0000)
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Recovery
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode : Normal
ME: Error Code : Image Failure
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : M0 kernel load
ME: BIOS path: Error
ME: found version 10.0.32.1000
ME: Wake Event to ME Reset: 84 ms
ME: ME Reset to Platform Reset: 753 ms
ME: Platform Reset to CPU Reset: 0 ms
todd@librem-13:~/proj/coreboot-dev/coreboot/util/cbmem$

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.

todd@librem-13:~$ cat /proc/cpuinfo | grep microcode | wc
 0 0 0
todd@librem-13:~$

LibrePlanet 2017

Don’t forget that we will be at LibrePlanet 2017 in Boston, showcasing the Librem 13 running coreboot, with a neutralized ME. I look forward to meeting you there!