Group:Hardware/Restrictions/anti-freedom/Intel Management Engine

Introduction

See the on the management engine on the FSF website for some background on why it is an attack on users freedom.

In a nutshell:

• The code it runs is nonfree
• That code is signed and required for booting the computer on recent computers
• It's designed to remove users control over their computers.
• Depending on the configuration, it can enable system administrators having configured it to remote control computers.
• The Management Engine also has extensive access to the hardware, and has some drivers or code to control some of the hardware, including various network interfaces, RAM, display, etc.

Compilation of information on ME versions

As the management engine evolved over time, many things changed. For instance the CPU architecture, the OS used in it, etc changed over time.

In addition to that, the number of research publications on the Management Engine are very small, and typically apply to a given Management Engine version.

As hardware we are interested in spans over more than a decade, and that work to make computers fully free can potentially take years, we also need to categorize on which Management Engine version it applies to.

While some information is specific to specific Management Engine versions, some other is specific to specific laptop models (and potentially revisions of variant of a given model).

This tries to summarize in tables what is known about specific Management Engine versions, or computers.

Versions

ME firmware version	Microarchitecture	Chipset	AMT versions	ME firmware versions	Applications	Location	Required modules	Bit
N/A (ME predecessor)		ICH7	1.0		AMT	82573E Gigabit Ethernet Controller	None	?
		Q963	2.0		AMT
		Q965	2.0	3.0	AMT No TPM
6.0 6.1 6.2	1st Gen Core: Nehalem? Other?						BUP	AltMeDisable
	Nehalem	Q57	6.0	6.0, 6.1
7.0 7.1	2nd Gen Core
8.0 8.1	3rd Gen Core
9.0 9.1 9.5	4th Gen Core
10.0	5th Gen Core: Broadwell Other?
11.x	Skylake						RBE BUP KERNEL SYSLIB	HAP
11.0	6th Gen Core
11.5 11.6	7th Gen Core

Computers

Board	Firmware	Microarchitecture	ME location and physical capabilities	ME restrictions
Lenovo Thinkpad X60/X60s/X60T	None.	I945 + ICH7	Inside the Ethernet controller, disabled: no Ethernet controller firmware.	Disabled: No Ethernet controller firmware.
Lenovo T60
Lenovo Thinkpad X200, X200s, X200t T400, T500, W500?	Me firmware with AMT and other modules	GM45/GS45	The ME is inside the PCH, it: Has access to the computer's memory/RAM Controls the computer's original networking adapters	Signed firmware The firmware can be completely removed in a way that keeps the computer functional.
Lenovo Thinkpad X201	Me firmware with AMT and other modules	Nehalem		Signed firmware If ME firmware is absent, the computer freezes about 30min after boot.
Packard Bell EasyNote LM85 (MS2290)	?			Signed firmware
Samsung Series 5 550 Chromebook (lumpy)	me.bin	Sandy Bridge		Signed firmware
Samsung Series 3 Chromebox (stumpy)	me.bin
Lenovo Thinkpad T520	Me firmware with AMT and other modules
Google/HP Pavilion Chromebook 14 (butterfly)	me.bin	Ivy Bridge		Signed firmware
Google Chromebook Pixel (link)	me.bin
Google/Acer C7 Chromebook (parrot)	me.bin
Lenovo Thinkpad X131e Chromebook (stout)	me.bin
Lenovo Thinkpad T530	Me firmware with AMT and other modules
Lenovo Thinkpad x230	Me firmware with AMT and other modules
Kotron KTQM77/mITX	?
HP Elitebook 2570p	? (need testing)
Google/Acer C720 Chromebook (peppy)	?	Haswell		Signed firmware
Google/HP Chromebook 14 (falco)	?

Reducing harm without fixing the issue

• There are several versions of the Management Engine OS for a given Management Engine hardware. Smaller versions can contain less code.
• me_cleaner can remove some of the Management Engine OS code.

However none of the above fixes the fact that nonfree code runs on hardware that has too many capability and that is meant to remove users control of their computer.

Research on removing the Management Engine OS

Because of the Management Engine, recent x86 Intel computers cannot even boot with free software.

However even if it's possible to disable the management Engine on Intel computers with more recent chipsets than the GM45 chipsets, this still need to be combined with the ability to boot the computer with only free software.

For instance, once a more recent computer boots without the Management Engine firmware, if that computer is not already supported by Coreboot or other boot software (u-boot, etc), support for it would still need to be added there and/or in downstream projects like Libreboot.

Even computers supported by Coreboot can also have other issues blocking the ability to boot with free software:

• Not many computers compatible with Coreboot have been tested without the nonfree CPU microcode. So it's a good idea to check if the lack of microcode doesn't prevent boot or reliable use of the computer.
• Many computers compatible with Coreboot do require nonfree software to boot. For instance, on recent Intel computers, Coreboot doesn’t do much anymore and most of its work consist in interfacing with nonfree binaries (like FSP) and running them to have the hardware initialization done.
• Some peripherals like GPU also need to be initialized at boot. So far ATI/AMD and Nvidia GPU cannot be used with fully free software as they require at least nonfree bytecode, and potentially Video BIOS if users need to see something during boot. Some also require nonfree firmwares. Some Intel GPU such as the ones used in the Libreboot compatible laptops are known to work with free software.

Removing the ME partition on platforms earlier than GM45

It's probably possible to remove the ME or AMT partitions on chipset before GM45 simply by not using the flash partition table.

Removing the ME partition on GM45

On The GM45 Chipset, the flash partition table can be configured to not have any ME partition. So it's possible to remove the ME firmware completely.

Though the ME probably has a bootrom, which probably hasn't been dumped for the GM45.

Removing the ME partition on post-GM45

Some computers, with more recent chipsets than GM45 are able to boot with the ME partition removed:

• There are some interesting bug reports in the me_cleaner bug tracker. Some people have removed the Management Engine OS on computers with chipsets more recent than GM45, but Coreboot hasn't been ported yet on such computers.
• There is a report of removing the Management Engine OS for an asus P55 Extreme, again Coreboot hasn't been ported yet to the computer.

However it is unknown if there are hardware issues that are only fixable from within the Management Engine: On GM45 Chipsets the method to remove the Management Engine firmware was supported by Intel even if it wasn't very well known publicly, before being used in free software projects.

So it's better to be sure that the people doing the reports on computers booting with the Management Engine partition being removed, use them daily, to limit such risk.

When code on the Management Engine is strictly required to boot

All the following research and attempts would in addition need someone to write free software code running inside the Management Engine to boot the computer.

It's still unknown how much work this could be.

DCI

It is possible to get JTAG through what is called DCI.

The idea is that it may enable to create modchip-like computers to boot recent Intel computers.

However, last time I checked using DCI still require:

• Nonfree software (called Intel System Studio) to be downloaded from Intel website in trial version. The DCI / red unlock would need to be reimplemented as free software.
• Another computer to run that software.

For targets having Skylake and above, the protocol that travels on the modified USB cable seems to fit within the USB3 specifications according to a blog post pt security.

It states (translated from Russian):

One of the important questions regarding USB 3.0 DbC DCI Hosting is whether any external USB 3.0 port can connect to DCI - or does it require a debug port, available only on dedicated motherboards for developers. This issue should be considered in more detail.

There is confusion among system developers, caused by the fact that debugging via USB itself appeared a long time ago (since the days of USB 2.0) and is currently used by many developers for software debugging of operating system kernels and UEFI applications. However, software debugging via USB (in windbg, UEFI debug agent, etc.) has nothing to do with hardware debugging mechanisms via JTAG, except for the transport itself. The USB 2.0 bus controller specification (EHCI, Enhanced Host Controller Interface) provides a special mechanism called the Debug Port (PCI capability) that allows communication between the server (software or hardware) on the machine being debugged and the client on the host. In particular, the Windows kernel supports debugging via the EHCI Debug Port (this requires a USB 2.0 debug cable,with an integrated USB 2.0 device). At the same time, indeed, not every external USB 2.0 port could work as a Debug Port, and this feature was assigned to certain ports that might not have been brought out. Everything depended on the manufacturer of the equipment. Therefore, the developers specifically looked for equipment with a Debug Port brought out to the outside, for debugging via USB. Thus, Debug Port is an attribute of the USB port.Debug Port is an attribute of the USB port.Debug Port is an attribute of the USB port.

However, the situation has completely changed with the advent of USB 3.0 and the specification of the controller of this bus XHCI (eXtended Host Controller Interface). This specification also supports USB debugging, but it has undergone significant development and became known as USB Debug Capability (DbC). According to XHCI, DbC is not a port attribute, but a property of a specific XHCI controller. That is, if this XHCI controller supports DbC, then USB 3.0 debugging will be available on any (including external) USB 3.0 port. At the same time, DbC will automatically select the first port to which the client performing USB 3.0 transactions is connected with a debug cable.

It is important to note here that the first XHCI controllers did not support DbC, so USB debugging was not possible on systems with such controllers. However, in PCH version 100 and above (for Skylake), Intel has built its own XHCI controller that supports DbC. Intel DCI technology (which appeared starting with Skylake processors) uses USB 3.0 DbC as a transport to connect a JTAG client. It does not use USB 2.0 Debug Port.

Thus, through any USB 3.0 port, you can connect to DCI and perform JTAG debugging. ".

It might also be used to understand more the Intel platforms, dump the ME bootrom? and find ways around the code signature?

References:

• https://github.com/ptresearch/IntelTXE-PoC and the associated blog posts
• https://kakaroto.homelinux.net/2019/11/exploiting-intels-management-engine-part-1-understanding-pts-txe-poc/

GPIO33 / HDA?

The Acer G43T-AM3 uses the Intel G43 chipset. According to its Coreboot documentation:

• There is a "ME_DISABLE" jumper on this mainboard. If set it pulls GPIO33 low.
• When ME_DISABLE is set, it "disables the ME" and "also disables any read/write restrictions to the flash chip that may be set in the Intel Flash Descriptor"

For GM45, the GPIO33 location is known for at least the Thinkpad X200.

However we lack information on what grounded on the GM45 and other chipset. For instance:

• What really happens when this pin is grounded?
• Does it also disable code signature on the Management Engine on more recent chipsets than the G43?
• Can we support more recent chipsets if we ground the GPIO33?

Upstream sustainability

Coreboot is removing many boards from new revisions of Coreboot.

Boards are typically removed because they weren't converted in time to new frameworks.

The issue is that one needs to already be involved in Coreboot development and follow very closely the mailing list, and what is happening to catch that early enough.

You could have less than one month to convert the code, if you don't catch it in time, especially because you are not contacted. It's up to you to follow what happening upstream.

While this lower the maintenance burden, as the maintainers don't need to care about converting the older code to the new frameworks, we also need to take it into account when deciding which computers to focus work on.

Here's what I know on that so far:

• The MAINTAINERS file has maintainers for specific computers. If a computer is maintained we probably have good enough assurance that it'll stick around.
• It's possible to pay some companies to do the maintenance work, but I don't have much information on that yet.

Why does that matters

While Coreboot itself is not FSDG compliant and expect users to download and use nonfree software for being able to use it on many computers, it's still interesting to have code maintained there.

This then enables FSDG compliant Coreboot distributions like Libreboot or the deblobbed versions of Coreboot published as part of the RYF initiative, to still be able to benefit from new developments and bugfixes upstream.

It also enables to build virtuous circles between non-FSDG compliant projects like Coreboot and downstream projects, where code can be maintained by the upstream project, even if the computers can't meet the RYF certification.

The x86 RYF laptops were made possible thanks to that kind of relationship: The fully free GPU initialization code was made by Ron Minnich for the Chromebook Pixel, which is a computer that is fatally flawed as it cannot even boot with free software as it requires a nonfree Management Engine firmware to boot. This code was then reused to get a fully free GPU initialization in Coreboot for the Thinkpad X60. Coreboot (once deblobbed) was then used to create Libreboot and make the first RYF laptops certified.

As compilers evolve, it's also important to still be able to build the source code without having to build very old compilers.

Other architectures

While not all computers using other architectures can even boot with fully free software, some can.

Using daily other CPU architectures like ARM, ppc64le, or RISCV can enable people to understand what is lacking on such architectures.

For instance:

• Trisquel doesn't work on ARM yet
• The Parabola ARM port doesn't have as many packages as x86_64
• Replicant can't be compiled from ARM computers yet
• If the tor-browser becomes FSDG compliant by removing its addons page, it's there are no releases for other architectures than x86 for GNU/Linux.

Working to fix common usability issues users find would be a good idea to get rid of the problem.

As for speed, other architectures are catching up or will catch up with the most powerful x86 computers that are RYF compliant at some point.

It's also now possible to do some benchmarks on that as a deblobbed version of the phoronix-test-suite was packaged in Parabola.

As for hardware support, we will probably have some RYF compliant System on a chip at some point, when the LIMA driver becomes good enough to be usable daily.

See also the Group:Hardware/FSDG_distributions page for background information for the architecture support of FSDG distributions.

See also

• The Wikipedia article on the Intel AMT
• The Wikipedia article on the Intel AMT versions
• http://me.bios.io/ME:About
• http://me.bios.io/ME
• Igor Skochinsky Paper very good and detailed presentation about ME
• decompress ME v6.x through ME v10 (prior to skylake)
• Disabling Intel ME 11 via undocumented mode
• The respective flashrom page

Credits

• This article is based on the old Coreboot wiki page on the Management Engine.