Why Intel will never let owners control the ME

Background

The Intel Management Engine is an auxillary microprocessor embedded into modern Intel x86 CPUs or chipsets.1 It runs an Intel-signed proprietary binary blob. Due to code signing restrictions enforced by the hardware, it cannot be modified or replaced by the user. (AMD x86 CPUs have a similar auxillary microprocessor, but they call it the Platform Security Processor. It's locked down in exactly the same way; the AMD situation cannot be considered to be any better.)

The ME firmware includes functionality relating to the system boot process, but also things like DRM functionality. It also supports remote management functionality (including an HTTP server, even) targeted at enterprise IT; this functionality allows IT departments to manage client machines remotely. It can access system memory without restriction. It can access the network.

Update (2018-07-24): Some people have interpreted parts of this article as a conspiracy theory. To explain the background better to people not already familiar with the ME, Intel is totally upfront about this scheme:

Intel blog post about their ME-based DRM scheme, which they officially call “Intel Insider”. Moreover, it's branded “Intel Insider” under the premise that it allows access to content that the media industry would be too skittish to provide without this kind of hardware-level DRM. In other words, this technology is openly directed at satisfying the media industry.

The book “Platform Embedded Security Technology Revealed”, which was written by the Intel employee who designed the ME and which you can read for free at that link. Chapter 8 discusses the DRM scheme.

Can the ME be disabled or removed?

This firmware cannot be removed. In response to the legitimate concern about the nature and capabilities of the ME, some laptop vendors have started advertising laptops with the ME “disabled” or “removed”. This is an exaggeration.

Although it's true on some older Intel platforms the system could boot without the ME, on modern platforms the ME/PSP cannot be disabled entirely because it is literally integral to the boot process in a modern system. A modern, high-performance multi-core chip is a complex beast and generally requires initialisation before the “normal” cores, the ones on which your chosen OS runs, start executing their first instruction. The x86 reset vector is a lie; a great deal happens before the BIOS starts running.

There are two solutions available today to reduce the threat level posed by the ME firmware: the “High Assurance Program” bit, and me_cleaner . The HAP bit is a configuration flag offered by Intel apparently at the request of the US government, and appears to disable most of the ME's functionality, leaving only the functionality critical to system operation running. me_cleaner removes optional modules from ME firmware images (this modification is possible because the modules are signed individually, so you can choose which modules to include), leaving only the ones critical to boot. Both of these provide a worthwhile and substantial reduction in attack surface. But this is not a total disablement or removal of the ME, and it's inaccurate to refer to it as such.

Why Intel mustn't allow you to control it

Intel/AMD will never allow machine owners to control the code executing on the ME/PSP because they have decided to build a business on preventing you from doing so. In particular, it's likely that they're actually contractually obligated not to let you control these processors.

The reason is that Intel literally decided to collude with Hollywood to integrate DRM into their CPUs; they conspired with media companies to lock you out of certain parts of your machine. After all, this is the company that created HDCP.

This DRM functionality is implemented on the ME/PSP. Its ability to implement DRM depends on you not having control over it, and not having control over the code that runs on it. Allowing you to control the code running on the ME would directly compromise an initiative which Intel has been advancing for over a decade.

Why did AMD do the same thing?

Though it makes it no less forgivable, AMD had no choice in the matter, because Intel defines the market. As far as I'm aware, Ultra-HD Blu-rays depend on this Intel DRM functionality; essentially, neither your OS nor the applications running on it ever see decrypted content, it's decrypted on the ME, which doesn't trust the OS to be secure (against you), and passed securely to your GPU. (I'm to understand GPUs have similar accommodations.)

As soon as Intel decided to do this, it was inevitable that AMD would also have to; if they were to decide to not follow Intel on this, they would be going to market with CPUs that can't be used to watch Ultra-HD Blu-rays (this would be a positive to me, but that's not how consumers work), and you can bet Intel would exploit this fact at every opportunity for a marketing advantage.

In other words, AMD's choices here are between doing the right thing and committing market suicide, and following Intel and being able to compete. For this reason the design of the PSP matches that of the ME from every perspective as regards owner control; the responsibility for the present state of affairs lies ultimately with Intel.

Could Intel or AMD make a version of their CPUs without DRM and let owners control that?

This is the logical next question: what stops Intel/AMD from providing variants of their CPUs which lack the DRM functionality, and for which providing control over the ME does not threaten theose schemes?

Interestingly, it transpires that there may be contractual obstacles to this. According to posts by an AMD employee on the Phoronix forums (see linked post and all following posts by the same user), AMD is contractually obligated not to reveal details about the internals of their GPUs, because those GPUs implement DRM and security by obscurity and the tiresomeness of reverse engineering is apparently part of what Hollywood's counting on. In other words, AMD may be contractually precluded from revealing the internals of a DRM-free GPU (to enable open source firmware to be developed, for example), because that DRM-free GPU would be so closely related, in terms of internal architecture, to a DRM-implementing GPU that it would provide useful information to people trying to break that DRM.

Although the above concerns AMD GPUs, it's not hard to imagine a similar dynamic in play for the ME/PSP. If Intel/AMD released CPUs with an owner-controllable ME/PSP, open source firmware would be likely to follow, and an understanding of the internals would be developed. By the above logic, Hollywood would perceive this as being helpful to people trying to break DRM on the sibling models which implement it.

It's basically stated that because of the above contractual obligations, it would be necessary for a DRM-free but owner-controllable design to differ significantly in its internals from a DRM'd design simply for the sake of being different, so that it doesn't reveal information about the DRM'd design.

Thus, for AMD to make CPUs or GPUs which are DRM-free but owner controllable would be likely to require substantial engineering R&D, for no other reason but than to satisfy these gratutitous contractual requirements. Intel/AMD are unlikely to do this unless they perceive sufficient market demand.

Summary

The x86 platform is a dead end from an owner-control perspective. See also: