[coreboot] More experiments with disabling the ME

Zoran Stojsavljevic zoran.stojsavljevic at gmail.com
Sun Nov 6 15:31:05 CET 2016

To Whom It May Concern!

I sincerely hope that Google designers, reading this thread, and are
involved in the R&D of multi-core silicon ARM server, with Coreboot
designers, will NOT replicate/copy such an opaque design as INTEL did (and
why, really???), and they'll get rid of ME entity overall/completely,
making simpler lookalike (hopefully Coreboot based) BIOS containing all the
components from INTEL BIOS + INTEL ME functionalities/features in one (in
other words migrate all ME functionalities in Google "BIOS", whatever this
will be).

The benefits of this design are obvious, aren't they? ;-)

Thank you,

On Sat, Nov 5, 2016 at 3:33 PM, Trammell Hudson <hudson at trmm.net> wrote:

> On Fri, Nov 04, 2016 at 09:20:24PM +0000, Nicola Corna wrote:
> > [...]
> >  * 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).
> I'm really glad to hear that you've been able to replicate my results
> and have similar results on slightly different hardware.  Since my original
> post I've also replicated the results on a Skylake mobile CPU, which has
> a very different ME architecture, although with a similar set of
> partitions.
> >  * 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").
> My guess is that it either has a fallback, a hard coded address or scans
> looking for the $FTPR string.
> >  * 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)
> Right.  I was confused since the coreboot architecture directory for the
> x230 is named sandybridge.
> > [...]
> >  * We couldn't remove in any way the FTPR partition on Sandy Bridge:
> [...]
> >  * Relocating the FTPR image doesn't work, even if the FPT entry points
> to the
> >     new location.
> Likewise. I also tried relocating it, but was not able to do so.
> >  * 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).
> I was able to reduce it to cover 0x3000 to 1 MB.  There appears to be some
> data being written into part of the SPI flash by the ME on each boot,
> logging someting about the startup?, so the IFD must include that portion.
> I did change the IFD to allow the CPU to read the ME region so that I can
> include it in my TPM measurements.
> >  * We haven't understood yet how to remove the unneeded modules from the
> >     partition, any help is appreciated.
> Any of the LZMA compressed files in the FTPR partitoin can be replaced
> with 0xFF.  The Huffman ones seem to share a common table, so I wasn't
> able to replace any of them individually.
> Again, I'm really glad to see that this has started additional research
> into this area.
> --
> Trammell
> --
> coreboot mailing list: coreboot at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161106/28e4fd2c/attachment.html>

More information about the coreboot mailing list