me_cleaner already exists[1], and it takes advantage of several flaws in Intel ME's signing to remove large sections of the code thus neutering it. Some code still exists, but Intel ME cannot actually fully initialise on "cleaned" systems. Older machines used to have a bug where if you filled the first half of the Intel ME firmware with zeros the machine would boot but ME wouldn't start at all.
But yes, I hope that with this it'll be possible to completely remove the remaining few hundred kB of Intel ME code remaining.
> That is, is a "cleaned" system vulnerable to a USB device?
of course it is, because the USB DCI attack is one level below the Intel ME. Even if it is deactivated via HAP, which basically simply puts the ME code into an infinite loop or a CPU halt state - both can be reversed by JTAG.
I don't know, because there is very little detail about what this attack is and how it works. It looks like they managed to thwart whatever protections exist in the USB DCI (Direct Connect Interface)[1] which is a debugging system for Intel chips.
If they have full debugger access to what's running in Intel ME then removing the code from the firmware probably doesn't make a difference (assuming they can run un-trusted code in that context). If they cannot write their own code and so an attack requires ROP gadgets then removing the code might make it harder (or impossible) to do, but I doubt it.
DMA-based attacks are blocked by the IOMMU, which is present in all modern machines (and has been for a few years). Linux has preferential enablement of DMA such that the IOMMU is initialised first, so even plugging in a device in early boot will not be able to exploit DMA.
But yes, I hope that with this it'll be possible to completely remove the remaining few hundred kB of Intel ME code remaining.
[1]: https://github.com/corna/me_cleaner