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
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.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, January 26, 2020 9:59 AM, Benjamin Doron benjamin.doron00@gmail.com 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.
On Sun, Jan 26, 2020 at 9:44 AM Mogens Jensen via coreboot < coreboot@coreboot.org> 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: Simon.newton@gmail.com
On Sunday, January 26, 2020 3:34 PM, Simon Newton simon.newton@gmail.com 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
-- Kind Regards,
Simon Newton
E: Simon.newton@gmail.com
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
-
Benjamin Doron -
Mogens Jensen -
Simon Newton