So ever since I heard Purism announced that they had officially purged Intel ME from their machines, I’ve been extremely interested in updating my Librem 15v3. That having been said, I’ve run into a few problems when trying to build the new coreboot image on my hardware.
For starters the ME Firmware RAR file has been updated so the script fails to verify the signature for the updated file. Fixing this was relatively easy and I was able to do so without any issue. Long story short: R48 became R49 and the previous R48 links redirect to the new R49 file. The comments in the script file indicate that the link and signature should be updated in the event of a change, so thats what I did.
Okay with that out of the way - I proceeded to move forward with the script and I now run into this error.
Built purism/librem15v3 (Librem 15 v3)
File build/coreboot.rom is 16777216 bytes
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
Flash Region 1 (BIOS): 00200000 - 00ffffff
Flash Region 2 (Intel ME): 00001000 - 001fffff
Flash Region 3 (GbE): 07fff000 - 00000fff (unused)
Flash Region 4 (Platform Data): 07fff000 - 00000fff (unused)
Flash Region 5 (Reserved): 07fff000 - 00000fff (unused)
Flash Region 6 (Reserved): 07fff000 - 00000fff (unused)
Flash Region 7 (Reserved): 07fff000 - 00000fff (unused)
Flash Region 8 (EC): 07fff000 - 00000fff (unused)
HEAD is now at 9facf98... Change debug line to avoid confusion with new --extra-partitions argument
Full image detected
The ME/TXE region goes from 0x1000 to 0x200000
Found FPT header at 0x1010
Found 11 partition(s)
Found FTPR header: FTPR partition spans from 0x2000 to 0xa9000
Found FTPR manifest at 0x2478
ME/TXE firmware version 11.0.18.1002
Removing unused partitions...
b'FTPR' (0x1000 - 0xa8000 (0xa7000 total bytes)): removed
b'FTUP' (0x110000 - 0x1bc000 (0xac000 total bytes)): removed
b'DLMP' (0x0 - 0x0 (0x0 total bytes)): removed
b'PSVN' (0xe00 - 0x1000 (0x200 total bytes)): removed
b'IVBP' (0x10c000 - 0x110000 (0x4000 total bytes)): removed
b'MFS\x00' (0xa8000 - 0x10c000 (0x64000 total bytes)): removed
b'NFTP' (0x110000 - 0x1bc000 (0xac000 total bytes)): removed
b'ROMB' (0x0 - 0x0 (0x0 total bytes)): removed
b'FLOG' (0x1bc000 - 0x1bd000 (0x1000 total bytes)): removed
b'UTOK' (0x1bd000 - 0x1bf000 (0x2000 total bytes)): removed
b'ISHC' (0x0 - 0x0 (0x0 total bytes)): removed
Removing unused partition entries in FPT...
Traceback (most recent call last):
File "./me_cleaner/me_cleaner.py", line 638, in <module>
mef.write_to(me_start + 0x14, pack("<I", len(new_partitions) / 0x20))
struct.error: required argument is not an integer
So if I’m guessing here my guess is that the parameters passed to the me_cleaner script specifically single out the MFS partition but this image has a partitioned named ‘MFS\x00’ instead. Perhaps thats MFS with a null character at the end of the string? I don’t know.
Anyway I’d reallly appreciate any insight anybody can offer here. I’d love to ascend to the next level of hardware freedom as soon as possible
I tried replacing the offending / with the // operator to get integer division instead, but that causes a different error somewhere else:
Traceback (most recent call last):
File "./me_cleaner/me_cleaner.py", line 640, in <module>
me_start + min_start, b"\xff")
File "./me_cleaner/me_cleaner.py", line 68, in fill_range
raise OutOfRegionException()
__main__.OutOfRegionException
I tried changing the '\0' in line 617 to '\x00' after seeing that the comment above it references ‘MFS\0’ but both of our outputs have “MFS\x00” but it didn’t help.
I don’t have any other clues yet, but I suspect it’s a different Python 2/3 incompatibility. For now, you can just hardcode python2 into me_cleaner.py and it builds and verifies just fine:
Hey, thanks @aarmea for figuring it out! I hadn’t thought of python 3. I’ll have to test against it next time and fix this. Maybe it’s already fixed since my changes got pushed upstream and Nicola Corna already adapted/fixed my patches.
The crash you saw couldn’t be fixed with the changes you attempted probably because the problem was that there were no partitions left at all (You see FTPR and MFS as ‘removed’ even though they are unremovable), so I’m just glad it crashed instead of letting you flash a completely empty ME which would have had unknown consequences.
@jaylittle The ME RAR being updated, I already fixed that, and made some changes so that if it gets updated in the future, the script will figure out the filename to use automatically and ignore the hash (it will still check the hash of the ME image inside of it, so that’s safe).
As for the ME status in cbmem, that’s exactly what we want, it’s because the ME is disabled, so coreboot can’t even access its status registers (it returns 0xfffffffff which coreboot interprets as all that). It’s explained here, where it says “a disabled ME simply doesn’t give us a status at all—so coreboot will even think that the ME partition is corrupted.”
Next week, I’ll look over the ME changes, see if upstream fixed the python 3 issues, then test, and update my me_cleaner branch so others using Arch won’t have this issue!
