[coreboot] Experiments with disabling the ME on Sandybridge x230

[Trammell Hudson]

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.

-- 
Trammell