ME extracted from vendor BIOS update?

[Mogens Jensen]

When compiling coreboot for my Intense PC, I used binary blobs extracted from stock firmware. The ME/TXE firmware version is 8.1.20.1336 and this contains multiple security vulnerabilities. Unfortunately, running me_cleaner on ME blob breaks SATA [1], so
next best thing is updating to latest ME blob released by CompuLab. However, this seems not so straight forward.

Latest BIOS update for Intense PC was downloaded from here:

https://fit-iot.com/files/download/intense-pc/bios/16-04-2018/ipc_2.2.400.5....

I unpacked and mounted the image like this:

# mount -o loop,offset=16384 ipc_2.2.400.5.img /mnt/

This is the interesting files found in /mnt/ afterwards:

81723002.ME (7843840 bytes)
BIOS_IMG.bin (16777216 bytes)

I tried to extract intel fd modules from BIOS_IMG.bin:

$ ifdtool -x BIOS_IMG.bin
File BIOS_IMG.bin is 16777216 bytes
  Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
  Flash Region 1 (BIOS): 00d00000 - 00ffffff
  Flash Region 2 (Intel ME): 00003000 - 00cfffff
  Flash Region 3 (GbE): 00001000 - 00002fff
  Flash Region 4 (Platform Data): 00fff000 - 00000fff (unused)

However flashregion_2_intel_me.bin is just an empty file and the ME data is in 81723002.ME:

$ hexdump flashregion_2_intel_me.bin
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0cfd000

$ me_cleaner.py --check 81723002.ME
ME/TXE image detected
Found FPT header at 0x10
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000
ME/TXE firmware version 8.1.72.3002
Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x
Checking the FTPR RSA signature... VALID

Setting location of 81723002.ME in CONFIG_ME_BIN_PATH during configuration of coreboot seems not to work.

Another important thing I found in coreboot documentation:

"Warning: Sandybridge Chipsets need a matching ME blob and IFD ! The board won't boot at all if one of them is invalid."

So if I understand correctly, I have to compile coreboot with the following files extracted from ipc_2.2.400.5.img:

flashregion_0_flashdescriptor.bin
flashregion_2_intel_me.bin
81723002.ME

The flashregion_3_gbe.bin extracted from stock firmware, also used when compiling coreboot the first time.

Does this sound right?

Also, what is the correct way to convert 81723002.ME into the proper flashregion_2_intel_me.bin?

Thanks in advance!

Regards,
Mogens Jensen

[1]:
https://github.com/corna/me_cleaner/issues/119

[Benjamin Doron]

As I understand it, the BIOS image simply has space reserved for ME in the
descriptor, which is what ifdtool can find. If me_cleaner or MEAnalyzer are
fine with 81723002.ME, provide it and the descriptor to coreboot. I don't
know about gbe so I can't comment on that.

The paths start at the root of the tree. The default ME location is
"3rdparty/blobs/$(MAINBOARDDIR)/me.bin", so try putting 81723002.ME there.

[Mogens Jensen]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 26, 2020 9:59 AM, Benjamin Doron  wrote:
> As I understand it, the BIOS image simply has space reserved for ME in the descriptor, which is what ifdtool can find. If me_cleaner or MEAnalyzer are fine with 81723002.ME, provide it and the descriptor to coreboot. I don't know about gbe so I can't comment on that.
>
> The paths start at the root of the tree. The default ME location is "3rdparty/blobs/$(MAINBOARDDIR)/me.bin", so try putting 81723002.ME there.

You're right. I don't know what went wrong, but I must have made a mistake as coreboot now compiles fine with 81723002.ME after trying one more time.

[Simon Newton]

On Sun, Jan 26, 2020 at 9:44 AM Mogens Jensen via coreboot <
[e-mail]> wrote:
> When compiling coreboot for my Intense PC, I used binary blobs extracted
> from stock firmware. The ME/TXE firmware version is 8.1.20.1336 and this
> contains multiple security vulnerabilities. Unfortunately, running
> me_cleaner on ME blob breaks SATA [1], so next best thing is updating to
> latest ME blob released by CompuLab. However, this seems not so straight
> forward.

Have you considered different permutations of me_cleaner - for example
using the AltMeDisable/HAP switch instead of the partition removal method?
i tend to do both the partition removal and the altme/hap switch, but some
motherboards simply dont like partitions removed.In those cases, ive used
HAP/altMEdisable  and ME has stayed inoperative. Theres a reason a certain
three letter agency asked for that switch to be there for their high
assurance platform. Id be surprised if the HAP switch setting didnt work -
try the lowercase -s switch.

Another area to consider would be whitelisting some FTPR modules when
running me_cleaner and see if that resolves the issue with SATA, if you
really have to run the partition removal method. Some of my mobos require
--whitelist EFFS,FCRS
>

Kind Regards,

Simon Newton

E: [e-mail]

[Mogens Jensen]

On Sunday, January 26, 2020 3:34 PM, Simon Newton  wrote:
> Have you considered different permutations of me_cleaner - for example using the AltMeDisable/HAP switch instead of the partition removal method? i tend to do both the partition removal and the altme/hap switch, but some motherboards simply dont like partitions removed.In those cases, ive used HAP/altMEdisable  and ME has stayed inoperative. Theres a reason a certain three letter agency asked for that switch to be there for their high assurance platform. Id be surprised if the HAP switch setting didnt work - try the lowercase -s switch.
>
> Another area to consider would be whitelisting some FTPR modules when running me_cleaner and see if that resolves the issue with SATA, if you really have to run the partition removal method. Some of my mobos require --whitelist EFFS,FCRS
> >
>
> Simon Newton
>
> E: [e-mail]

I have not tried to run me_cleaner on the blob myself, I got the information on broken SATA from the me_cleaner GitHub bug report.

I rely on internal programmer, so I have not made too many experiments in fear of bricking the system. But if system still boots from USB after messing with ME, I can make some experiments with me_cleaner, as a disable ME would be better than anything else.

Regards,
Mogens Jensen