Why are you moving the goalposts? Your question was specifically how to completely disable it, not how to lobby AMD/Intel into removing the feature from the silicon...
His point is still valid: how do you know it's disabled other than "just trust me"? If I was the NSA, I'd work very close with OEMs to bug the rare order with "Intel vPro™ - ME Inoperable, Custom Order" checked; bit like https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa...
But by that measure, how do you know the platform doesn't have yet another remote control feature that you don't know about? Do you trust the platform or don't you?
Ultimately, you can't. From Ken Thompson's "Reflections on Trusting Trust" [0], written in 1984:
> The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well-installed microcode bug will be almost impossible to detect.
You can trust a system by accepting that if it is owned, you are owned. If you don't trust it you instead protect it with a system that you do trust. For example, if you don't trust any x86 system you would not make them face the Internet. You would put them behind a trusted firewall.
But you have to decide whether you trust a system or not. If you trust it then you have to believe it when it reports a certain feature is disabled. If you don't trust it to begin with then it doesn't matter if it's disabled or not. Your security shouldn't be relying on it anyway.
