Wow all 6th, 7th and 8th gen are all vulnerable along with a bunch of Xeon processors. Even the laptop I am typing this on is vulnerable, this is going to be messy. Plus all the fun vulnerabilities like arbitrary code execution, unauthorized access to privileged content. These must be related to the blackhat talk coming up in December about hacking a turned-off computer and running unsigned code on ME [0]. Yep and the two researches doing the talk are the two people credited in this announcement, Mark Ermolov and Maxim Goryachy. Great work by them finding these vulnerabilities and disclosing them, these are the kind of vulnerabilities that the NSA would salivate over.

I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. The cynic in me thinks that this will change absolutely nothing.

There is a great website called The Bad Thing [1] that has compiled the known information about Intel ME.

I just ran the detection tool on my laptop and I am running a vulnerable version of Intel ME, but I can't even do anything about it until my system manufacturer provides a patch for it. I feel like this is going to be one of those situations that ends up leaving millions of devices unpatched and vulnerable a few years down the road.

[0]: https://www.blackhat.com/eu-17/briefings/schedule/#how-to-ha... [1]: https://www.cs.cmu.edu/~davide/bad_thing.html

> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden.

I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there.

In corporate use, these tools can be incredibly useful. If they were more transparent, then they could be used by normal users for remote administration as well.

But it needs to be secure, and it needs to exist without secrecy. If this portion were free for the user to configure, or if they allowed complete disabling via motherboard jumper, or simply open sourced it, that would be a better step.

However, the NSA's activities have destroyed all trust in these sorts of features coming from an American company, so even if it were completely open sourced, there's no guarantee that there isn't other hardcoded ROM also executing in tandem with the open source components.

> or if they allowed complete disabling via motherboard jumper

That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.)

All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonomously by the PCH these days, with the CPU just asking the PCH to "get it done." And the logic that runs in the PCH to interpret those requests and decides when and how to apply them, is executed by the ME.

The ME only managed to not exist previously, because mainboards were previously both "simpler" (every bus spoke exactly one protocol and the controller chip for that bus did the protocol signalling) and more complex (tons of single-purpose controller chips.) The PCH boils all that down to one chip, and it needs a CPU to do it, and that CPU is the ME. Getting rid of it would mean going back ~15 years in computer capabilities.

(Another way to think of the PCH is that it's basically an SoC chip, with the "heavy lifting" of application execution moved out to a separate, upgradable CPU socket. But, like any SoC, it still does need some sort of internal CPU. The ME is that CPU.)

>> or if they allowed complete disabling via motherboard jumper

> That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.)

Then how does Intel disable it for governmental customers (high-assurance)?

The GP is simply wrong on many/most of its technical claims. ACPI implementations were common for 4+ years before the ME existed. The ME is not involved in DRAM refresh or initialization at all (other than waiting for it to complete..). DRAM refresh is hardened into the IMC, and the initialization SW runs on the x86_64 cores - typically it's a UEFI binary blob provided by Intel. Once the OS is running, it manages the IOMMU, and the IOMMU itself is a hardened function; the translations that it performs for the OS do not involve the ME. And so on.

Though the ME currently performs some complex early initialization tasks, the notion that a modern x86_64 platform simply cannot work, or cannot work efficiently, without the ME running indefinitely/alongside the OS is plainly wrong.