Re: [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.

Experiments with disabling the ME on Sandybridge x230

[Peter Stuge]

Trammell Hudson wrote:
> 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.

Please do read the book. It's quick, you'll need at most three hours.

http://www.apress.com/9781430265719

//Peter

Experiments with disabling the ME on Sandybridge x230

[mdn]

I just subscribed to see.
Look at the pic.
what do I do.

Le 20/09/2016 20:31, Peter Stuge a écrit :
> Trammell Hudson wrote:
> > 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.
>
> Please do read the book. It's quick, you'll need at most three hours.
>
> http://www.apress.com/9781430265719
>
> //Peter

Experiments with disabling the ME on Sandybridge x230

[Karl Schmidt]

On 09/20/2016 01:31 PM, Peter Stuge wrote:
> Trammell Hudson wrote:
> > 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.
>
> Please do read the book. It's quick, you'll need at most three hours.
>
> http://www.apress.com/9781430265719

\

Interesting read - I see many problems in assuming security:

- It is too complex
- Not open code
- Likely back doors.
- traffic with Internet without user knowing or able to see

If I want a platform to hold business and financial information, I don't want closed ME code running 
that can be shut down from the outside - or pass traffic that I can't see. This gets to the key 
reason for coreboot - and unless we can completely replace/remove the ME code  - I see this as less 
security not more.

In an earlier time I managed some EEs and a software team - very bright folks, but they had one 
blind spot - they were used to being among the brightest in the room and would correctly assume that 
no one else would understand what they were doing.  But, if you apply the resources of a 
nation-state or even a wealthy crime syndicate, over time they will figure it out and find a way in. 
  The more complex, the more likely there will be a hole - intentional or not.

In my mind the risk to world financial systems from back-doors is quite real and underestimated.

With out an open BIOS I think the best advise is to keep business intellectual property isolated 
from the Internet. At some point we need a machine with open storage hardware firmware as well..

It would be quite different if Intel was providing information and tools to roll your own ME code. 
Have to assume they were made an offer they couldn't refuse to be doing what they are.

The questions I have is if this is mostly for the DRM stuff that one doesn't need in a work 
environment or for some 3LA.