4 ms·

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 pr

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.

nickpsecurity 9y ago
"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.