Technically there are two aspects to ME cleaner
Only the former is useless on that Intel Gen CPU (and presumably all later generations), as I understand it.
It was strictly engineered to the purpose: free backdoors, but we never know.
HECI is for sleep, which can still wake up without user consent. HAP is for Disabled permanent and still permit to boot.
Thanks for the correction. I updated my post to be clearer.
I assume by âpermanentâ you mean ⌠until next power-on.
Doesnât nuke the whole ME region. Always dump a .bin of a BIOS if youâre going to modify it⌠And always keep a .bin.bak to make sure you have a dump that is known-goodâŚ
Tunnel vision is a dangerous thing when it comes to security. Sure, itâs good to focus on things sometimes but it leaves you blind for everything else. Even though is seems smart to stare at âME(NSA)â backdoors [I mean, it was there in the title, I couldnât resist 
], you should never assume that A) any modern complex device can not have flaws that can be exploited, intentional or not (this is why we have layered security - nothing is foolproof, just fool resistant), B) even if one isnât known now, something weak or odd could be found later, C) there can always be more than one (and +1 [or +N]), and D) that just one specific entity could use them [â+1â rule here too] (this is the problem with all the arguments of intentional backdoors also - bad actors will always get access too and even good actors with good intentions are likely to turn into bad ones - even if just for one time). Also, a single weakness by itself is not enough (due to layers but also environment complexities) to make a system useless or fully insecure (relative to risk profile).
While I agree that tunnel vision is dangerous ⌠the concern about the IME is that it operates at such a low level, having complete control over almost everything.
As a perhaps hypothetical concern ⌠any code that runs even before the main CPUâs boot firmware could probably run the boot firmware in a virtualised environment, such that the boot firmware doesnât even realise that it isnât running on bare metal, and that could have some pretty interesting implications for security.
However the IME doesnât even really need to do that because it has ongoing low level access to almost everything - and can subvert almost all other security measures.
I disagree. The CSME (ME) is a completely separate CPU/SOC, a 32 bits Quark architecture Pentium (old!). It could not execute any of the real CPU boot sequence nor firmware - only the main CPU can do its own reset vector and bootblock stage. Furthermore, running a virtualised environment inside ME is not possible: it has no vmx flag and canât do virtualisation. And also it has no memory except its tiny on-dye 1.5MB SRAM, until DRAM init is done (which is corebootâs romstage fsp-m init_memory call) and this must execute on the main CPU.
But this was only a hypothetical concern, just as you said - I just wanted to explain why this would not be a feasible bypass.
I didnât mean âvirtualised inside the MEâ. I meant virtualised on the main CPUs.
You raise a good point about whether the IME can access memory before the main CPU has done DRAM init - because the IME does normally have full access to the memory.
For the more technically inclined, a detailed description of the IME and CPU interactions after power-on:
As can be seen, after its reset vector the ME co-processor has no RAM except for its own on-dye 1.5MB SRAM. At this point, it can only load (from the SPI flash ME region) the 4 basic modules needed for starting the main CPU and then have it connect and train DRAM (an incredibly complicated process on modern cores.)
But it does nothing in the meantime, waiting for the main CPU to send the DID (DRAM_Init_Done) signaling that DRAM is now available - after this, it can load many more modules, runtimes and tasks from SPI ME region.
The 4 basic modules loaded before more memory is available, are: RBE, KERNEL, SYSLIB and BUP.
RBE (ROM Bypass Enable) is updated boot ROM code which will bypass the on-dye mask-ROM; its purpose is to correct eventual bugs/vulns found in the original ROM code, which cannot be replaced on the SOC dye.
KERNEL and SYSLIB are the (modified) MINIX 3 micro-kernel. All 3 modules run at ring 0 and BUP in less privileged userland for separation/isolation.
This BUP module (BringUP) is the code that sets up the hardware for the main CPU to do its reset vector at 0xFFFFFFF0 (16 bytes below the 4GB top of addressable memory hardware-mapped to SPI flash by the PCH.) This internal mapping corresponds to the SPI flash BIOS region, hence it is the coreboot BootBlock, the first instructions the main CPU executes - we have control very early in the boot process!
It is only after corebootâs bootblock stage execution that romstage will call FSP-m binary blob, which will setup MMU and train DRAM. When init_memory call returns - and only then - we have the DRAM online and DID signal sent to ME.
During all the time while the CPU runs the above-mentioned initial coreboot stages, the ME does absolutely nothing but wait for DID signaling that memory is available. It can then load more modules.
That is: if there are more modules to be loaded, because with Nicola Cornaâs me_cleaner, everything else could be removed from the SPI flash ME region, an extraordinary achievement (neutralization) that guaranties no other ME code can run but for those 4 required modules.
Addendum: the above explanation relates only to ME firmware 11.xx, Skylake and Kabylake 6th and 7th gen (later Librem 15/13 models.) Unfortunately things are more complicated for later generations (e.g. Librem 14), due to the inability to cleanse and therefore neuter unwanted/undocumented code from ME; a huge attack surface in ring -3 compared to ME 11.xx firmware family.
In a sense, late Librems 15/13 will remain for a long time the safest and smallest attack surface to remedy the hard to solve IntelME problems and uncertainties.
Full citation of image slide?
The Phantom Menace: Intel ME Manufacturing Mode. Mark Ermolov & Maxim Goryachy
Hitbsecconf2018 pdf at https://conference.hitb.org/hitbsecconf2018dxb/materials/D1T1%20-%20The%20Phantom%20Menace-%20Intel%20ME%20Manufacturing%20Mode%20-%20Maxim%20Goryachy%20and%20Mark%20Ermolov.pdf
I see, it was one of the many inline references from a blog article I linked recently on the Purism community forums:
See also:
Yes, I read everything Eclypsium publishes and thatâs probably (I canât remember for sure) where I found a reference to this excellent presentation at Hack-In-The-Box 2018 from Mark Ermolov & Maxim Goryachy of Positive Technologies
I miss the diamond that asks âLoad from Tape or DIsc?â
See also:
