Pandora's Box: The Intel Management Engine

We frequently receive questions regarding the Intel Management Engine. This article has been written, hopefully, to explain what it is, why and how we disable it, and most importantly, how to check if it has been disabled. This should typically be the same for all hardware but was written with ours in mind.

What is the Intel Management Engine?

The Intel Management Engine is an autonomous subsystem that has been included in all modern Intel Core processors and chipsets. The Management Engine processor runs its own proprietary firmware provided by Intel.

The correct term for this, in recent chipsets, is the Converged Security and Manageability Engine (CSME), and in an effort to clear up incorrect assumptions, we'll only refer to it as such going forward. The main reason it is necessary is that it performs the BUP (Bring-up Process) for the processor (i.e. turn it on), and for that reason, it's not possible to remove it.

There have been several theories over the years about what it does, and many of these are confused with AMT (Active Management Technology). AMT is another binary that was designed to aid remote administration. It runs off the CSME and has extensive capabilities, such as turning on computers, reading network traffic, performing firmware and software updates.

It can be a useful tool for system administrators managing a large number of computers. However, AMT is only present on 'vPro' variants of Intel products. We don't use any vPro variants, so we won't mention that anymore.

As for what the CSME can do itself, as far as we are aware, only Intel know the full extent of its capability. However, we can discern many of its functions and what it cannot do. While its capabilities are far more limited than AMT, one being that it can't turn the computer on, it's not a feature set that anyone is likely to need - so we switch it off.

How do we disable it?

One of the common misconceptions is that coreboot is needed or is the thing that disabled the CSME. That's not true - it can also be done with the AMI BIOS.

An analogy for this would be comparing them to Word Processors. coreboot is a firmware platform like AMI. coreboot could be compared to LibreOffice Writer as it's open-source and AMI to Microsoft Word.

The fact that one is open-source makes no difference to the result, a Word document. They have different capabilities and styles, and more on this can be read here.

Another misconception is that the only way to disable the CSME is by using the me_cleaner. This was a project designed to be able to disable and, if desired, delete as many parts of the CSME as possible whilst still allowing the BUP to function. The action of deleting parts of the CSME has been referred to by some as "neutered".

The me_cleaner, whilst it has its merit, isn't adequately maintained anymore, with the last updates dated back to 2018 - long before many of the processers we use were made. There are snippets here and there to add support for newer processors. Using these snippets, it is possible to assemble something that will disable and delete parts of the CSME.

From our testing, the process of deleting sections of the CSME can cause instabilities. This isn't too surprising as me_cleaner intentionally corrupts it; imagine if you had a Word document and deleted the middle of it, it's unlikely that you'd be able to open it, let alone see what's inside it.

Fortunately, Intel did eventually add a way to disable the CSME, to the point where only the bare minimum remains active that's required for BUP, and rumour has it that this was added upon the request of the NSA.

We, therefore, opted to use the method that allows us to disable or enable the CSME at will, as this proved very reliable and allowed us to check that it had turned off as intended.

AMI already had a method of disabling the CSME, but when we started using coreboot, there wasn't a way to do the same. So we added one, and this can be found here.

How do you check it's disabled?

There's many methods for checking, but only one that is guaranteed to give reliable results. We'll briefly touch on why.

Probably to most common method is to use the intel_me_tool. This, like the me_cleaner, hasn't been updated since 2017. It attempts to check the status of the CSME via a PCI Interface. The problem with this is that if the PCI interface alone is disabled, it will report there is no CSME where in reality, it just can't see it. Many programs have the same flaw, such as chipsec and fwupd, but this is mainly as they were designed to check a fully operational CSME, specifically one that it is up to date.

The way to categorically test is to check the firmware debug logs. For AMI, this is a complicated process that requires specialised hardware. We have this available here, but many components had to be built so it's not a viable method for most.

This is not the case for coreboot, as there is a publicly available tool to extract the debug logs from Linux. It's called cbmem and can be found here. The process for installing this would be:

git clone https://github.com/coreboot/coreboot.git
cd coreboot/util/cbmem
make
chmod +x cbmem

You can then run the below command to print out the relevant parts of the debug log:

sudo ./cbmem -1 | grep ME

You'll see a whole lot of information in here. The bit we're looking for is the Operation Mode of the CSME, where 0 is Normal or On, and 3 is disabled.

Below are sample outputs with the CSME Enabled and Disabled.

Enabled

ME: Current Working State   : 5
ME: Current Operation State : 1
ME: Current Operation Mode  : 0
ME: Error Code              : 0

Disabled

ME: Current Working State   : 4
ME: Current Operation State : 1
ME: Current Operation Mode  : 3
ME: Error Code              : 2

This is standard code in coreboot, so it should work on any recent hardware running coreboot.