> and it actually has nothing to do with hypervisors, unless you take the metaphor that any operating system you install is really running under the control and whim of the Intel Management Engine

What I meant was that, the same way the userland runs at the control and whim of the kernel, and the kernel at the control and whim of the hypervisor, the hypervisor itself will run at the control and whim of IME. Because IME sits at ring -2 (yes, that's a thing now), the hypervisor at ring -1, the kernel at ring 0, and userland at ring 3. So it's actually more than "hypervisor-level access", but a hypervisor is almost as capable, so it's a decent comparison.

> ...except it could be used to deliver similar functionality...

That's what I was trying to communicate, yes. The purpose (not the functionality) of IME is to enable enterprise management. Like Group Policy or Configuration Profiles, like server backplane management, like running your app as a VM on a hypervisor, like a lot of things.

The point is that these technologies exist to enable companies to control and manage their hardware assets. None of them are built in such a way that they can reach out and bite you if they haven't been set up and configured by the computer's owner, any more than someone could interface with your computer's serial console without attaching a serial cable to it.

A lot of devices come with privileged backdoors, for a variety of reasons. For example, a lot of CPUs have a JTAG debugger chip embedded, exposed via GPIOs. But since such backdoors require hardware access to enable, they're not all that scary. Of course your device isn't secure if someone gains physical access to it. While they were in there, they might have also installed a Bluetooth-transmitting in-line keylogger chip or something.

Now, what might be scary about IME is that it's enabled by default. But a lot of things are also insecure by default until hardening is applied, and have to be secured in a clean-room environment: Windows, for example. If you care, you do this.

But I don't see its existence in particular as troubling, insofar as it doesn't represent any greater loss of control than was already true. Intel chips (and I'm pretty sure those of most other CISC manufacturers) have been running microcode updated via encrypted blobs for decades; this microcode can have any number of backdoors embedded in it. You don't need a fancy special-purpose coprocessor to do this stuff; the main processor is perfectly capable of doing Intel's bidding instead of yours without any help. The IME just allows your computer to do the bidding of some arbitrary third-party that Intel likes (like DRM companies), instead of the code needing to be written by Intel themselves, embedded deep in the CPU's internals.

Note also that most firmware chips can be re-flashed to do bad things; CPUs are not alone in presenting this "bugged out-of-the-box" attack-vector.

...but then, to go one step further: if you don't trust Intel's chips because of their firmware, why does it matter whether it's firmware or not? Backdoors can be embedded in the traces of the CPU itself. Having updatable microcode doesn't change this; the existence of the IME doesn't change this. Do you think the NSA can't requisition a one-off custom variant printing of a CPU, and get that stuck the board of a Person of Interest's laptop, or phone, or TV, instead?

This is why I was concentrating on the Intel AMT (remote Internet access) feature of the IME: it's the only part that materially changes things from how-the-world-was before its existence. If you're an end-user and own your computer, you can disable AMT, and verify that it's disabled—the computer will no longer reply to probes on that port. Everything else is just a dozen new vectors for motivated attackers to do things motivated attackers have always been able to do.