The most you can do is drop it to some kind of reduced functionality mode some time after boot (through the HAP bit, or hackery which overwrites part of the flash memory). This is why dishonest vendors like Purism resort to confusing terminology like "neutralize".
https://x.com/rootkovska/status/939058475933544448 https://x.com/rootkovska/status/939064351008395264
While yes you cannot strictly disable the ME, what remains of its firmware in this configuration is a bringup module that is stuck in a loop handling power management events.
The network stack, HECI stack, etc are all gone here. Effectively the only way to exploit it is to put your payload into SPI flash, which we are already doing anyways :)
It is also possible to take over the ME firmware and bring up the CPU using open source code, and have full control over the ME at runtime. This isn't implemented currently, but that's the direction this is aiming in.
I think there is a misunderstanding. Intel ME is a hardware feature. Yes there is some flash memory which contains more code and an operating system, but what is stored in flash memory is only part of Intel ME.
Peter Stuge from Coreboot noted during his 30C3 talk that even if you completely zero out the flash, it is possible for Intel ME to send a network packet out of the ethernet interface. The cutoff point when this started happening is the 965 chipset around 2006.
https://media.ccc.de/v/30C3_-_5529_-_en_-_saal_2_-_201312271... (relevant part starts at 17:19)
The only code that is inside the silicon is a 128K bootrom that literally just sets thing up for the real firmware to run.
One of the benefits of deguard for Intel MEv11 is that it sets the ME in such a state where you can run unsigned code in there. This is how the Intel Boot Guard was disabled, because it is the ME that enforces such restrictions; more information about deguard is available on a dedicated page.
The deguard utility could also be used to enable the red-unlock hack, which would permit unsigned execution of new CPU microcode, though much more research is needed. Because of these two facts, this makes the T480/T480s the most freedom-feasible of all relatively modern x86 laptops.
With deguard, you have complete control of the flash. This is unprecedented on recent Intel systems in Libreboot, so it’s certainly a very interesting port!
...Dell? I have multiple of their machines which have been configured via their B2B panel to have ME fully disabled.
The bringup module always boot which configures the clock controller, bootguard parameters, and releases the CPU core from reset. When in HAP mode, after that it only handles power management events and doesn't really do anything else. No other ring 3 processes are started on the ME in this mode.
Stuff like even the real read-write VFS, fw updater, HECI comms handerl, AMT, PAVP, ISH server, etc are never started in HAP mode. It effectively reduces your runtime attack vector to data in SPI flash only.
As mentioned in one of the linked tweets, ME was possible to exploit through early-boot attacks before the HAP bit was even checked. So non-negligible things happen while it "boots".
While they are genuine vulernabilties, I wouldn't consider this a worse problem than being able to inject rootkits into other parts of the firmware which is also the case here.
And the understanding that we have is mostly limited to what is in flash memory, e.g. the ME's BootROM hasn't been dumped yet (as far as I am aware).