Right. ME does make sense as a feature for sysadmins. Except . . . . Well, can you shed light on the following:
1. Why did your team deem it necessary to deny the end-user the capability to disable this feature?
2. Why did your team decide to enable ME on ALL consumer grade chips? You could have only enabled it on, say, Xeon, as a value-add - exactly like you do for ECC support. You could have made more money this way. But . . . you didn't.
Without legitimate, sensical answers to the above questions, there is no reason for anyone to believe your team did anything other than design a backdoor for the Feds. Sorry.
Having been a sys-admin once upon a time (2006-2008), these answers are straight forward. Servers used to have discrete ME cards which were paid add-ons. Competition in the early 2000s drove these ME cards to be integrated in the motherboard in order to better compete on the low end of the market. I’ve had servers I was only able to remotely fix due to the out of band management interface (more than once). They pain they fix is real.
The same techniques for managing server farms are useful for managing hundreds/thousands of corporate desktops. Being able to power up a desktop (“lights out” management) and re-image it at 3:00AM is very useful for example. You could also install 3rd party security products to the ME to provide higher level threat detection that’s hard for a rootkit to hide from. So once the work of getting an integrated management engine production ready was complete, it made perfect sense to use it in corporate desktops. It’s expensive to produce chip variants, so doubtless that further cost pressures on Intel lead to them putting the ME their core shared across all products. Plus, now IT admins can let the VP of Sales get the laptop she wants knowing they can leverage their System Center/OpenDesk/etc. console to manage it via ME.
So no, they aren’t a Fed backdoor. Those of us who worked in IT 10 years ago remember how the market drove Intel to add the ME. That is doubtless why many are silently conflicted. They don’t want to take a big step back. They likely are expecting/hoping Intel will “fix” the problem.
The problem isn't the existence of the ME as such. Servers have a BMC which implements similar remote management functionality. People could order servers without BMCs, since they're discrete chips, but they don't.
Even Raptor's high-security Talos II has a BMC; the issue isn't having a BMC, the issue is that it's not owner controlled and it's not auditable.
What's wrong with the ME is that
a) it only accepts Intel-signed code; I can't replace the ME firmware with an implementation (e.g. of remote management functionality) that I trust. I also can't repair vulnerabilities in it without the cooperation of both Intel and the vendor (which is often not forthcoming).
Consider the Authorization header bug in the ME's webserver and multiply it by how many machines you claim use this remote management functionality. That's horrifying.
b) it has DMA access to main memory, which is insane.
Look at the fact that every server nowadays has a BMC, in addition to the ME. On a client device the ME would be used to implement similar functionality, so the BMC is actually a wasteful duplication - but server vendors have to use a BMC because they can't program the ME to implement the remote management functionality they need, because only Intel can program the ME. This is stupid.
> It’s expensive to produce chip variants, so doubtless that further cost pressures on Intel lead to them putting the ME their core shared across all products.
Would it be possible in future CPU designs to put a jumper in, e.g., the ME power path? Closed by default (and possibly forced closed in enterprise-targeted devices), but the option exists to disable the ME without requiring an additional CPU variant.
From a hardware perspective, it’s an easy problem to solve. This is a wetware problem, however.
Back when ME’s were discrete, you would inevitably have some with, some without. Someone would order a bunch of machines without them to “save money” or they bought a model that just didn’t have an ME add on offered by the OEM.
That meant that occasionally you had to actually have the machine in your presence to service it. You end up designing two processes/procedures based on whether you are remote or not. Lack of ME’s actually increased labor costs by reducing the number of machines a tech could manage (on average).
Having an CPU fuse essentially winds the clock back to the discrete ME days. Someone will place an order order for SKU ENCH-81-U instead of EMCH-81-U and you end up with 500 machines with the ME fuse blown. Inevitably there will be a big enough restock fee that someone in accounting will say “just use them.”
(The same applies to things like having/not having a TPM module, etc.)
I'm not OP, but to respond to question 1, allowing users to disable the feature would also allow attackers to disable the feature. If you're relying on ME to provide remote access so that you can clean and repair infected machines, then it's game over for you if the attacker can disable ME.
It would have made much more sense to require you to enable it before first use, and ship it as disabled from the factory. Enablement should work like blowing an eFuse where it's never off once it's turned on, but if you never turn it on it doesn't exist. Then I don't have to worry about the feature unless I know exactly what it is and how to use it.
"I'm not OP, but to respond to question 1, allowing users to disable the feature would also allow attackers to disable the feature."
Older products had jumpers, physical switches, or software mechanisms for securely updating firmware. The first two are immune to most types of remote attacks if done in hardware. Intel already uses signed updates for microcode which people aren't compromising remotely left and right. Intel supporting a mechanism like those that already existed in the market for disabling the backdoor would not give widespread, remote access to systems. If anything, it would block it by having less privileged, 0-day-ridden software running.
I'll also note that the non-Intel market, from OpenPOWER to embedded, has options ranging from open firmware (incl Open Firmware itself) to physical mechanisms to 3rd-party-software. Intel is ignoring those on purpose for reasons they aren't disclosing to the users that also probably don't benefit them.
> Why did your team decide to enable ME on ALL consumer grade chips?
Can you please provide a reference? I've been trying to enable ME forever for my consumer-grade i7 with Intel motherboard for remote management, and I can't seem to be able to.
The core of Intel ME is enabled on all chips since 2008. But features like remote management aren't. Intel ME is used for things like DRM (see PASP) or hardware bring-up and power management.
I looked into something similar recently. The following is based on plenty of research, but Intel's information can be a bit ambiguous and incomplete at times, so I can't promise I have every detail right.
FOR OTHERS: Note that you might be able to disable ME's remote access simply by ordering a computer with "No VPro".
1. ME is a platform with many applications that run on it; AMT (Active Management Technology) is one of them.
2. AMT has many components; remote management is one of them.
3. AMT comes in multiple 'editions' (my word, not Intel's) with different features. The Small Business Technology (SBT) edition does not provide remote access by design, with the idea (AFAICT) that small businesses don't want to setup and manage management servers and therefore remote access is insecure.
4. If in MEBx[0], you see "Small Business Technology", then there's no remote management - unless there's another remote management function in ME that is independent of AMT. Also, the first reference below provides the official method of identifying SBT implementations (via a flag in some table). I discovered it on a system ordered with a "No VPro"[1] network card (I'm still not sure why that's a spec of the NIC and not the processor).
[0] MEBx is Management Engine BIOS Extension: the text-mode, pre-OS console UI for configuring ME
[1] VPro is not a product or technology. It's merely branding for, AFAICT, an ambiguously defined group of products that IT professionals might be interested in. It includes AMT (which is also part of ME and often marketed independently), TXT (Trusted Execution Technology), and more.
1. Why did your team deem it necessary to deny the end-user the capability to disable this feature?
2. Why did your team decide to enable ME on ALL consumer grade chips? You could have only enabled it on, say, Xeon, as a value-add - exactly like you do for ECC support. You could have made more money this way. But . . . you didn't.
Without legitimate, sensical answers to the above questions, there is no reason for anyone to believe your team did anything other than design a backdoor for the Feds. Sorry.