It's not hard to imagine an alternate universe in which we all have RISC workstations with the equivalent of ME, and Intel/AMD are the minorities who have more "open" CPUs without, but only because they hadn't grown enough.
The underlying reason why ME became popular is the same reason why proprietary walled gardens became popular: because they are heavily promoted as a security/safety feature, and "who doesn't want to be safe and secure?"
Remember that, shortly before the turn of the century, Intel was convinced by the masses to remove a feature that would seem almost innocuous today, a serial number, but only because they marketed it as for DRM/identification instead of a security feature:
... is also because it provides management features that are wanted by enterprise customers. If you're running hundreds of servers in a data center, the more management you can do remotely, without visiting the machine room and preferably automated as much as possible, the better.
This is quite irrelevant and even undesirable for an individual's personal computer.
Admins use the ILOM/IPMI for servers, so you don't really need it for server CPUs. For laptops all management happens at the operating system level, not below it.
[1]: https://downloadcenter.intel.com/download/15362/index.htm?ii... [2]: https://www.youtube.com/watch?v=v0mwT3DkG4w
Since the boot process already involves some amount of hand holding from outside the CPU, any of those features could have been provided by a designed-for-enterprise motherboard with ME-like features in the BIOS/UEFI or even some sort of peripheral in the PCH (or wherever).
Second, competition is exactly what we need to get rid of hardware backdoors and unwanted features. If I had the coice to buy a PC without closed firmware and hardware, I would do so. The more open, the better. We direly need competition there.
Scott McNealy, Sun Microsystems (1999): "You have zero privacy anyway. Get over it."
Wow! And look where we are now. Quite the irony how things played out.
It could be an open solution too. I have only cursory followed OCP and other hardware advances, but this being used with Raptor's power servers. Opensparc before Oracle, and recently the RISC V community might have built something similar too.
You can build such features without baking the keys into the hardware. You can have an open security module where changing the key simply makes everything that has been previously secured by it unreadable. That way a user can load his custom keys and firmware if he wants to. You can cascade that dependency down the secure boot chain by mixing some secret from the module into the HDD decryption for example.
Only vendor lock-in (e.g. windows RT) and DRM require hardcoded keys.
I'm all for national governments making their own hardware not subject to backdoors installed by other national governments, but there's a huge difference in capability between Russia and, say, Lebanon.
Incidentally this is one reason I think the UK is daft to leave the EU.
1. Or the government or one of it's contractors. I've even sat through meetings 12 engineers sat around and argued about what to name something internal. I started calling this "name by committee".
And even if there is, the "non-evil" reason for keeping this as is might be that "enterprise customer doesn't want something that is easily disabled, and we can't justify cost of a separate design / fab run for a small minority of customers", vs. "Haha, now we have a backdoor into EVERYTHING!"
(Hell, even the proposals about disable via hardware switch, or having the ME on a separate component probably boil down to money. To an outsider, hardware companies are funny beasts in that they really start caring about things like counting pennies and minimizing BOM cost as much as possible. I've been in worried meetings where we were literally counting and debating pennies, and wondering how I got there, but it makes sense at a company level since those pennies add up when you are building thousands or millions of something! This may have boiled down to "motherboard manufacturer doesn't want to have to put another mechanical part on the board, and they are looking to buy a shitload of our parts, let's keep them happy")
Please note: I'm not saying, or even advocating, that this is a good thing, or results in ideal outcomes when I say "benign". I'm just using it in the sense that this likely wasn't a malicious decision, but probably one motivated by money at some point, by people who didn't necessarily see the harm in it.
Lots of return on that investment. Lots of reasons unrelated to those you mention.
There are opensource ways to do out of band management without it.
>consumer benefits. Related tech also helped DRM machines through Trusted Computing alliance.
Nobody I knew who was knowledgeable wanted that shit in the first place. It was always edging away consumer control of the platform. DRM is part of the problem here! Same thing with web standards. What annoys me the most about this is the audacity of calling it "consumer benefits".
>probably got defense contracts or payments for selective use by NSA or other organizations
Fine, but that's not a good enough reason to backdoor literally everything for everyone else. (reminds me of systemd and redhat actually)
> There are opensource ways to do out of band management without it.
I'd be surprised if there is a cost-effective open source alternative to this requirement: Remotely access and control a computer under any circumstance where it has power and a physical network connection. Solutions like AMT work even if there is no functioning processor or memory, because ME provides its own processor and memory. The open source alternative would need the same hardware.
At best, it would mean the corporate IT department designing, buying, installing, integrating, and supporting additional hardware, for tens of thousands of computers. That's very hard to justify when the computers come with hardware already installed, integrated with everything else, and supported by the vendor.
If someone could put FOSS on ME (or competing proprietary solutions), I'd be all for it. I suspect it would be very difficult, as we can't even figure out how to disable ME.
On top of that, I should note they do this without assistance of the Intel ME. The remote KVM access is handled through a video adapter embedded in the BMC.
Our team has several racks of R&D servers 7500km away from the bulk of the team, and having OOB management is vital. Absolutely vital.
The claim that extant FLOSS solutions can stand in for AMT was false, but now the replies to that have set up a false dichotomy.
The opposite of a monstrously complicated, buggy proprietary interface with undocumented features is a compartmentalized, robust proprietary interface with a fully-documented public interface. "Sorry, we don't want to show you the design specs for our hardware." "Sorry, we don't want to show you the code for our secret sauce." That's fine. Just give the bits that can be flipped to slide all the way from maximum ease like your R&D use case to maximum lockdown like a Bitcoin-based service.
What happened to 3rd parties making chipsets? Another case of Intel abusing it's monopoly?
VIA used to make dual socket server class chipsets, for the pentium 3, which ever age was in.
The cost of IoT devices supports what you are saying.
Seems like they mention chipsets, but didn't go far enough given what happened to Nvidia chipsets vis-a-vis GPUs. They could do a little bit better as a regulator.
http://www.mercurynews.com/2010/02/13/nvidia-gains-ally-agai...
SPARC has been open for years FYI.