Zoran --
Thanks for your insights on the ME. It's quite a messy bit of HW and it makes no sense to me why Intel has it shrouded in such secrecy. There is no reason that I can see for it to be undocumented.
[...] Link to the very useful presentation (I clipped the above figure): http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
Igor's 2012 presentation and 2014 update have been very helpful as I have been poking at the ME, especially the layout of some of the structs in the firmware partition table and partition headers.
As an update to my previous message, I've built an even more reduced ME firmware that has removed a few modules from the FTPR partition:
UPDATE, HOSTCOMM, RSA, CLS, TDT, ClsPriv and SESSMGR can be replaced with 0xFF and the ME will still initialize the system correctly. This leaves only ROMP, BUP, KERNEL, POLICY and FTCS.
[...] Essentially, talking about ME, we are talking about the PCH's HW entity, which has the complete CPU inside itself, called ARC (32 bit, not sure if this is a RISC, high probability it is)
On Sandybridge/Ivybridge it is the ARC CPU, radare2 has a dissassembler and the files can be decompressed with http://io.netgarage.org/me/
[...] Something like this: ME partition gets downloaded to PCH, where it occupies small SRAM area, for the beginning.
There must be some amount of on-chip ROM as well, since the FTPR code is Huffman compressed. The decompressor also checks a signature on the partition header, so we can't modify many of the fields in the header.
Then ME initializes Integrated Clock Controller (ICC). Then BIOS starts booting. BIOS thread of execution is the following (the best I could invision from the patchworks reachable to me):
[1] Initializes VGA (via PCIe port);
[2] Initializes Host Embedded Controller I/F init (via HECI PCIe port);
[3] Then BIOS/HECI initiates communication with ME/MEI;
[4] BIOS continues with DDRAMx MRC;
[5] Upon finishing MRC, BIOS/HECI communicates with ME/MEI;
[6] ME starts booting ARC 32bit Threadx RTOS kernel;
[7] ME reserves on the DDRx's TOM (Top Of Memory) 32MB UMA region solely for its own (application) use!
That matches my understanding as well, with the exception that the UMA region appears to be configured immediately after MRC execution in the BIOS.
Coreboot, upon bringing up, does NOT know about HECI I/F (my best guess) and ME (and MEI).
I believe Coreboot does both HECI and MEI, depending on the chipset. For the bd82x6x it uses MEI via PCIe. If it didn't talk to the ME, the UMA would never be configured and (I believe) the ME wouldn't make any progress past its bring up.
That might also be an easy way to neutralize the ME; if it is never given any resources, can we prevent it from doing anything bad?
[...] Then, it is easy to imagine that FTPR is THE only ME component, which needs to be executed, since it is essentially part of INTERNAL ME init!
And I'm hoping that by removing the rest of the code that there is nothing in the on-die ROM that has additoinal backdoors. With the network device driver and java bytecode interpreter gone, I also hope that the ME can not be subverted by an outside party.