[coreboot] Experiments with disabling the ME on Sandybridge x230

Sun Sep 18 16:08:11 CEST 2016

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 at 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' 0000E909
>
> This 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 at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160918/87c2538a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 258449 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20160918/87c2538a/attachment-0001.png>