PGP Fingerprint: B8CA ACEA D949 30F1 23C4 642C 23CF 2E3D 2545 14F7
Latest posts by Todd Weaver (see all)
- Purism Warrant Canary Updated July 1st 2017 - July 1, 2017
- How Purism Avoids Critical Intel Security Exploit - May 8, 2017
- How Purism avoids Vault 7 leaked threats “Dark Matter” - April 25, 2017
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:~$
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!