<div dir="ltr">Hello Trammel and Coreboot community,<div><br></div><div>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. ;-)</div><div><br></div><div>Well... Good job, very well done from Trammel's side. I'll try to show two sides of this ME equation:</div><div>[1] ME functionality.</div><div>[2] MEI (ME communication component) and HECI (BIOS communication component), two components which from the very existence communicate with each other.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">So, let us (at first) try to understand the following (by Trammel's investigation):</div><div class="gmail_extra"><br></div><div class="gmail_extra"><i>"<b><font color="#ff0000">The only piece that must be present for my x230 to function is the 512 KB<br>FTPR partition</font></b> at offset 0x183000, which contains these compressed<br>modules (some Huffman, some LZMA):<br><br>      'UPDATE' 000001BE<br>      'ROMP' 0000070A<br>      'BUP' 0000E064<br>      'KERNEL' 00021B62<br>      'POLICY' 00016AE2<br>      'HOSTCOMM' 00006DDB<br>      'RSA' 00005255<br>      'CLS' 00005791<br>      'TDT' 000066E5<br>      'FTCS' 00004680<br>      'ClsPriv' 000003E1<br>      'SESSMGR' 0000E909"</i><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The accent/stress is on <b><font color="#ff0000"><i>RED</i> </font></b>text. This belongs to Part [2] I already mentioned: MEI and HECI and their communication.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The table presented belongs to part [1]: ME functionality.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Let us look to the following table (courtesy Igor Skochinsky):</div><div class="gmail_extra"><br></div><div class="gmail_extra"><img src="cid:ii_15739a5ccef5778f" alt="Inline image 1" width="472" height="258"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Link to the very useful presentation (I clipped the above figure): <a href="http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub" target="_blank">http://www.slideshare<wbr>.net/codeblue_jp/igor-skochins<wbr>ky-enpub</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">How this communication looks like? Something like this: <span style="font-size:12.8px">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):</span></div><div class="gmail_extra"><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[1] Initializes VGA (via PCIe port);</span></p><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[2] Initializes Host Embedded Controller I/F init (via HECI PCIe port);</span></p><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[3] Then BIOS/HECI initiates communication with ME/MEI;</span></p><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[4] BIOS continues with DDRAMx MRC;</span></p><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[5] Upon finishing MRC, BIOS/HECI communicates with ME/MEI;</span></p><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[6] ME starts booting ARC 32bit Threadx RTOS kernel;</span></p><p class="MsoNormal" style="font-size:12.8px"><span lang="EN-US">[7] ME reserves on the DDRx's TOM (Top Of Memory) 32MB UMA region solely for its own (application) use!</span></p></div><div class="gmail_extra">_______</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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!</div><div class="gmail_extra"><br></div><div class="gmail_extra">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).</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div><div class="gmail_extra"><a href="http://www.slideshare.net/codeblue_jp/igor-skochinsky-enpub" target="_blank">http://www.slideshare.net/code<wbr>blue_jp/igor-skochinsky-enpub</a><br></div><div class="gmail_extra"><a href="https://software.intel.com/en-us/amt-sdk" target="_blank">https://software.intel.com/en-<wbr>us/amt-sdk</a></div><div class="gmail_extra"><a href="https://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface" target="_blank">https://en.wikipedia.org/wiki/<wbr>Host_Embedded_Controller_Inter<wbr>face</a></div><div class="gmail_extra"><a href="https://software.intel.com/en-us/blogs/2007/01/24/let-us-talk-about-heci-and-lms" target="_blank">https://software.intel.com/en-<wbr>us/blogs/2007/01/24/let-us-tal<wbr>k-about-heci-and-lms</a><br></div><div class="gmail_extra">_______</div><div class="gmail_extra"><br></div><div class="gmail_extra">Two final considerations here:</div><div class="gmail_extra">[1] Hope this will help somehow (expecting comments and discussions)!</div><div class="gmail_extra">[2] We can (Coreboot members) continue discussing/writing about ME, trying to do the best to demystify INTEL ME Voodoo Magic! ;-)</div><div class="gmail_extra"><br></div><div class="gmail_extra">Best Regards,</div><div class="gmail_extra">Zoran Stojsavljevic</div><div class="gmail_extra">_______</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 15, 2016 at 9:23 PM, Trammell Hudson <span dir="ltr"><<a href="mailto:hudson@trmm.net" target="_blank">hudson@trmm.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Mon, Sep 12, 2016 at 09:27:18PM +0000, Peter Stuge wrote:<br>
> Trammell Hudson wrote:<br>
> > I've experimented with clearing additional bits, from 0x3000 to 0x10000<br>
> > with the same results.  If I were really motivated I might binary search<br>
> > how much of the firmware it needs...<br>
><br>
> That would be interesting.<br>
<br>
</span>After a fairly brief binary search, I have determined a significantly<br>
reduced chunk of code required to have the Intel Management Engine bring<br>
up the hardware and then stay in the "ROM Phase".  This also allowed<br>
me to adjust the flash descriptor to give an extra 3 MB of storage to<br>
coreboot for my payload, as well as removed some of the problematic<br>
ME applications.<br>
<br>
The only piece that must be present for my x230 to function is the 512 KB<br>
FTPR partition at offset 0x183000, which contains these compressed<br>
modules (some Huffman, some LZMA):<br>
<br>
      'UPDATE' 000001BE<br>
      'ROMP' 0000070A<br>
      'BUP' 0000E064<br>
      'KERNEL' 00021B62<br>
      'POLICY' 00016AE2<br>
      'HOSTCOMM' 00006DDB<br>
      'RSA' 00005255<br>
      'CLS' 00005791<br>
      'TDT' 000066E5<br>
      'FTCS' 00004680<br>
      'ClsPriv' 000003E1<br>
      'SESSMGR' 0000E909<br>
<br>
This means that the ME no longer has any network stack (stored in the<br>
NFTP partition that has been removed), nor the protected video path<br>
or JCOM modules from the MDMV parition.  I do not know if the various<br>
anti-theft and timeout measures are also now neutralized.<br>
<br>
If I leave the firmware partition table at offset 0x3000 in place,<br>
the ME faults after bringup (but the system continues to function).<br>
Without the partition table it stays in the ROM phase.  I'm not sure if<br>
one outcome is preferable to the other.<br>
<br>
Relocating the FTPR partition did not work unfortunately, so there is<br>
some wasted space.<br>
<span><font color="#888888"><br>
--<br>
Trammell<br>
</font></span><div><div><br>
<br>
--<br>
coreboot mailing list: <a href="mailto:coreboot@coreboot.org" target="_blank">coreboot@coreboot.org</a><br>
<a href="https://www.coreboot.org/mailman/listinfo/coreboot" rel="noreferrer" target="_blank">https://www.coreboot.org/mailm<wbr>an/listinfo/coreboot</a><br>
</div></div></blockquote></div><br></div></div>