I can't get with justifying one serious security problem using another. Attackers increasingly combine local privilege escalations to move laterally, but only need one RCE to get in.

Windows can be booted into test keys mode, which allows the loading of unsigned drivers. We don't consider that a security issue because the privileges you need in order to switch to that mode are equivalent to the privileges you get by switching to that mode. It's the same here - the ME is the root of trust on Intel platforms. If you're in a position to execute arbitrary code on the ME then you've already got the ability to compromise the rest of the system enough to run arbitrary code on the host CPU, and being able to modify microarchitectural state doesn't give you additional privileges.

I’m not saying that’s the case here, but that’s the general problem with the line of reasoning that “hey if you already have permission X then doing Y is the least of your concerns”.

The concept of defense in depth literally relies on each barrier being independent and robust. That’s why you see hardening of Linux’s hibernate even though the common refrain is “well if you have physical access the game is lost”. There are things that even root can’t do even though “hey if you have root the game is lost”. The point of the game is to never lose even in very adverse environments.

The assumption on Intel is that there are no barriers once you're in the ME. You can't defend against a hostile ME. The security model is already violated. Maybe there should be a barrier between the ME and the CPU, but as can be seen here Intel feel that the ME should be in a position to put the CPU in debug mode so shrug.

Where can I read about "hardening of Linux’s hibernate"? I'm curious

I suppose one possible scenario is:

- Police confiscate your laptop on some bogus pretext, then return it to you saying you're free to go.

- You open the laptop and find nothing that shouldn't be there. You wipe it, reinstall the OS and continue using the laptop.

- Surprise! The CPU now works for the police, so after some time it installs a rootkit or whatever.

Dunno if the microcode is big enough to do this kind of attacks, and perhaps some other firmware is easier to program.

But if someone waves this off saying that's not how police works in the US, well the world is larger than the US and it all definitely happens in other countries, only without CPU rootkits so far.

Situation without this CPU feature: Cops compromise the ME, disable Boot Guard, compromise your firmware, backdoor your OS directly Situation with this CPU feature: Cops compromise the ME, disable Boot Guard, compromise your firmware, backdoor your CPU so it can later backdoor your OS

There's not really a meaningful difference between these! If there's an exploitable ME vulnerability then the police can absolutely own your system in an undetectable way regardless of whether or not this feature exists. If we were in a different universe where the ME enabled whether or not the CPU was in debug mode but wasn't responsible for any other security features then we'd care about this a great deal more, but as long as compromising the ME already gives you a way to permanently backdoor the system it's doesn't make any real difference.

You mean NSA and the same, but online?

There are more productive ways to view the probabilities of security. Low probability may imply low risk but is not guaranteed to imply low priority to fix.

Am I correct in surmising that a successful run of me_cleaner will prevent the abuse of these instructions?

No. me_cleaner reduces the amount of code running on your ME, and as such reduces the attack surface presented by the ME. But anyone with physical access (which is required for the interestingly exploitable ME vulnerabilities) is in a position to just put whatever ME firmware they want on your system.

Yeah, like a rootkit on the cpu.

Or the only thing to worry about