[coreboot] More experiments with disabling the ME

[Nicola Corna]

Hi everybody,

Me and Federico Amedeo Izzo (federico.izzo42 at gmail.com) started looking into our
Intel ME firmwares after reading the thread "Experiments with disabling the ME
on Sandy Bridge x230" started by Trammell Hudson.

We have two Thinkpad X220 (Sandy Bridge) and a X201 (Nehalem), and we obtained
the following results:

 * Sandy Bridge accepts an Intel ME firmware with just the FTPR partition, both
    with and without a valid FPT (the partition table of the Intel ME image).
    The system doesn't power off after 30 minutes, and the ME reports a
    successful initialization (see attached cbmem).
    To be extra safe we wrote a small Python script that removes all the
    non-fundamental partitions and creates a new FPT with a single partition
    entry (following the structure in [1] and some hints from Igor Skochinsky).

 * Sandy Bridge boots successfully without a good FPT (but with a valid FTPR),
    so it probably has a "backup" on-chip FPT. The system boots fine and doesn't
    power itself off after 30 minutes, even if the cbmem entry "ME: FW
    Partition Table" has the value "BAD" (that, we suppose, means: "I found a
    broken partition table, I'm using the fallback one").

 * According to Trammell Hudson's tests, this behaviour is the same in Ivy
    Bridge (the thread's subject says "Sandy Bridge" but his cbmem confirms that
    his device is actually an Ivy Bridge)

 * Nehalem (on our X201) seems to lack a "backup" on-chip FPT, as removing the
    FPT partition bricks the device.
    Moreover using an ME image with just FPT and FTPR results in a brick,
    Nehalem probably needs more parts of the blob than just FPT and FTPR.
    Unfortunately our X201 is in a bad state and its flash is about to die, so
    we can't test further on Nehalem.

 * We couldn't remove in any way the FTPR partition on Sandy Bridge: setting the
    entries number to 0, the UMA size to 0 MB, creating an invalid FPT with a
    bad checksum or creating a "fake" FTPR entry which points to an empty region
    leads to a bricked device. Apparently, no matter which trick is used, if ME
    can't find the FTPR partition it refuses to boot.
    We didn't try with a 0-sized partition, but the result is probably the same.

 * Probably the UMA size can be reduced from the "stock" 16 MB or 32 MB to few
    MB, we'll investigate on this.
 
 * Shrinking the "reduced" ME partition in IFD to the minimum size allowed (FTPR
    offset + FTPR size + 4 kB alignment) bricks the device too (but we're not
    sure about this, maybe we made a mistake during the image creation).

 * Relocating the FTPR image doesn't work, even if the FPT entry points to the
    new location.

 * We haven't understood yet how to remove the unneeded modules from the FTPR
    partition, any help is appreciated.

 * The cbmem's ME entries
    * ME: Current Working State   : Normal / Recovery
    * ME: Bringup Loader Failure  : YES / NO
    * ME: Progress Phase          : ROM Phase / BUP Phase
    seem to be interesting, and should be studied further.

Attached you can find the script we used to "clean" the ME images, the cbmem log
of an untouched ME image (the 2.1 MB firmware extracted from a Acer Chromebook
C710) and the cbmem log of the same image after executing the script on it
(therefore with just the FPT with a single entry and the FTPR).

Some help testing the further options would be nice, in particular on the
Nehalem architecture.
Be careful: messing with ME may cause a hard brick, without the 30 minutes
window, requiring an external programmer to unbrick your PC.

Nicola Corna
Federico Amedeo Izzo

[1] http://me.bios.io/ME_blob_format
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbmem_ftpr_only
Type: application/octet-stream
Size: 75386 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161104/995e9e5d/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cbmem_full_me
Type: application/octet-stream
Size: 75362 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161104/995e9e5d/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: me_cleaner.py
Type: application/octet-stream
Size: 3501 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161104/995e9e5d/attachment-0005.obj>