Hello Trammel and Coreboot community,
I am following this thread, and thinking... I decided to get involved, but not after carefully thinking about how I can put (some, not all) of my ME knowledge in prospective. Since the area you have touched is very complex, and somehow very peculiar, I should say. I'll let you all judge my answer, and degree of peculiarity. ;-)
Well... Good job, very well done from Trammel's side. I'll try to show two sides of this ME equation: [1] ME functionality. [2] MEI (ME communication component) and HECI (BIOS communication component), two components which from the very existence communicate with each other.
These two sides are inevitable twisted and they are inseparable, considering INTEL philosophy, which follows actually INTEL business model. And Coreboot and Linux are certainly not part of this philosophy, NOT at the beginning, in 80s and 90s of last Century.
So, let us (at first) try to understand the following (by Trammel's investigation):
*"The only piece that must be present for my x230 to function is the 512 KBFTPR partition at offset 0x183000, which contains these compressedmodules (some Huffman, some LZMA): 'UPDATE' 000001BE 'ROMP' 0000070A 'BUP' 0000E064 'KERNEL' 00021B62 'POLICY' 00016AE2 'HOSTCOMM' 00006DDB 'RSA' 00005255 'CLS' 00005791 'TDT' 000066E5 'FTCS' 00004680 'ClsPriv' 000003E1 'SESSMGR' 0000E909"*
The accent/stress is on *RED *text. This belongs to Part [2] I already mentioned: MEI and HECI and their communication.
The table presented belongs to part [1]: ME functionality.
Let us look to the following table (courtesy Igor Skochinsky):
[image: Inline image 1]
Link to the very useful presentation (I clipped the above figure): http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub
This very closely matches Trammel's investigation... And, to be more punctual, the ONLY access to this area has exclusively ME HW (which is located inside PCH).Tthe CPU itself and BIOS do NOT have access to it.
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), but ARC HW (driven from inside PCH's embedded FW) accesses from its side flash descriptor, and reads/transfers at one point in time the whole ME partition to the PCH's embedded SRAM). This partition has multiple parts, and one of them is FTPR (kernel in here does mean Threadx RTOS kernel for ARC).
Now, let me try to explain what happens with [2] MEI and HECI communication... Let me repeat: MEI (ME communication component) and HECI (BIOS communication component), two components which from the very existence communicate with each other.
How this communication looks like? Something like this: ME partition gets downloaded to PCH, where it occupies small SRAM area, for the beginning. 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! _______
Coreboot, upon bringing up, does NOT know about HECI I/F (my best guess) and ME (and MEI). It has no idea that all of this (scary, isn't it) is sitting aside... Actually confirming INTEL HW/FW + WINx SW creation/orientation, warped in late 1990s by Linux influence.
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!
In other words, Coreboot and ME are/must be asynchronous entities (for boot-loader Coreboot use case), which should not know about each other, and ME initially (early stage) controls main CPU solely by HW signals (RESET signals releases), releasing it after it initialized ICC, and after accomplishing transfer of ONLY active FTPR partition to the internal PCH's SRAM. All other ME partitions/components MUST be incapacitated, since they are there serving for/to BIOS/ME interaction and security (my best guess).
This reply is assembled solely from the public net sources (and I sewed lot of details using my INTEL ME knowledge ;-) ), some of which are presented below: http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub https://software.intel.com/en-us/amt-sdk https://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface https://software.intel.com/en-us/blogs/2007/01/24/let-us-tal k-about-heci-and-lms _______
Two final considerations here: [1] Hope this will help somehow (expecting comments and discussions)! [2] We can (Coreboot members) continue discussing/writing about ME, trying to do the best to demystify INTEL ME Voodoo Magic! ;-)
Best Regards, Zoran Stojsavljevic _______
On Thu, Sep 15, 2016 at 9:23 PM, Trammell Hudson hudson@trmm.net wrote:
On Mon, Sep 12, 2016 at 09:27:18PM +0000, Peter Stuge wrote:
Trammell Hudson wrote:
I've experimented with clearing additional bits, from 0x3000 to 0x10000 with the same results. If I were really motivated I might binary
search
how much of the firmware it needs...
That would be interesting.
After a fairly brief binary search, I have determined a significantly reduced chunk of code required to have the Intel Management Engine bring up the hardware and then stay in the "ROM Phase". This also allowed me to adjust the flash descriptor to give an extra 3 MB of storage to coreboot for my payload, as well as removed some of the problematic ME applications.
The only piece that must be present for my x230 to function is the 512 KB FTPR partition at offset 0x183000, which contains these compressed modules (some Huffman, some LZMA):
'UPDATE' 000001BE 'ROMP' 0000070A 'BUP' 0000E064 'KERNEL' 00021B62 'POLICY' 00016AE2 'HOSTCOMM' 00006DDB 'RSA' 00005255 'CLS' 00005791 'TDT' 000066E5 'FTCS' 00004680 'ClsPriv' 000003E1 'SESSMGR' 0000E909This means that the ME no longer has any network stack (stored in the NFTP partition that has been removed), nor the protected video path or JCOM modules from the MDMV parition. I do not know if the various anti-theft and timeout measures are also now neutralized.
If I leave the firmware partition table at offset 0x3000 in place, the ME faults after bringup (but the system continues to function). Without the partition table it stays in the ROM phase. I'm not sure if one outcome is preferable to the other.
Relocating the FTPR partition did not work unfortunately, so there is some wasted space.
-- Trammell
-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
