[coreboot] More experiments with disabling the ME

[Igor Skochinsky]

Hi Nicola,

Nice work! I would like to add some comments inline.

Friday, November 4, 2016, 10:20:24 PM, you wrote:

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

AFAIK there is no "backup FPT", there is just the internal boot ROM
which tries to load the main fimware from the ME region and fails if
FPT is bad/missing. On failure, it does set the FW status registers
which are visible on the host side in the PCI device config space,
which is how you can see the "FPT bad" bit and the boot phase. I
think it just happens that on this platform the boot rom does just
enough hw initialization for the rest of the boot to work, even
without the BUP and all other code. 

Incidentally, I believe that FTPR stands for "Factory partition (&recovery)"
and contains the minimal modules required for the successful boot of the host
and firmware update process (during firmware update, the FTPR is updated last,
so that the system can still boot if the update fails at any earlier stage).

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

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

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

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

You can try using Intel's Flash Image Tool to construct the flash
image from the ME and BIOS regions and see if it makes a different
IFD.

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

This is probably due to the Huffman-compressed modules, which use a
table of offsets to compressed chunks and those offsets are from the
start of the ME region. This table will need to be relocated too.
For more info, see references to "LUT" in unhuffme[1] source code.

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

You can't do that as the whole partition header ("manifest") is
protected by the RSA signature, including the module table. I've just
uploaded to my github[2] a script (me_sigcheck.py) which allows to
check the validity of the signature, so you can try various
modifications yourself.

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

It seems "Recovery" in your case may be caused by the missing MFS
partition (MFS failure : 0x1). What you can try is to copy a clean MFS
partition from a non-initialized ME image[3] - this way it will pass
the check and maybe not go into the recovery. It may then be possible to
shrink the MFS partition to a minimal size to gain more space.

[1] https://io.netgarage.org/me/
[2] https://github.com/skochinsky/me-tools
[3] http://www.win-raid.com/t1658f39-Guide-Clean-the-Engine-Initialized-DATA-section-of-a-SPI-dump.html


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

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

NC> Nicola Corna
NC> Federico Amedeo Izzo

NC> [1] http://me.bios.io/ME_blob_format




-- 
WBR,
 Igor                            mailto:skochinsky at mail.ru