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-sec...
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