ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : NO
ME: Manufacturing Mode : YES
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: D3 Support : NO
ME: D0i3 Support : YES
ME: Low Power State Enabled : NO
ME: Power Gated : NO
ME: CPU Replaced : NO
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (4)
ME: Current Operation State : Preboot
ME: Current Operation Mode : Normal
ME: Error Code :
ME: Progress Phase : BUP Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : 0x65
ME: Power Down Mitigation : NO
ME: FPF status : unfused
REDACTED@mojo:~/coreboot/util/cbmem$ cat /proc/cpuinfo | grep microcode | wc
4 12 68
Yeah… that information is for the Librem 13 v1. It’s much harder to verify if the ME is disabled on the skylake system and that was the last thing I was working on. The way I do it is to just dump the flash and used a hex editor to check if the ME in it is neutralized or not (zeroed out modules and removed partitions), but obviously that’s not practical for anyone.
Unfortunately, I think coreboot is booting so fast on the skylake systems that it finishes booting and probing the ME before the ME encounters its first “module missing” error and crashes.
There’s the intelmetool in coreboot which could be used to talk to the ME and see if it responds to requests or not, but it hasn’t been ported to skylake yet I think. I suppose that for now, you just need to trust that if you flashed it and enabled me neutralization, that it is indeed neutralized.
Tried the current script today in the vain hope this might fix issues with the new Qubes4.0rc2 not recognizing IOMMU/VT-D as enabled. Unexpectedly though it produced some fatals & warnings and finally broke when it found the hash of the downloaded ME repo to be wrong.
Script was run from a fresh PureOS with additional necessary packages installed on a Librem13v2. I logged the whole output: http://dumptext.com/10v1R18M
Hereby pinging @kakaroto about this. Any ideas what might have gone wrong?
@avog: well that’s interesting, thanks for the log. I tested and I got the same issue. It looks like the mediafire link had its file updated. The ME repository pack went from r48 to r49. I always thought the medialink files were static, so I thought the r49 (when they’d upload it) would be a new link, but it looks like that’s not how it works. Anyways, I’ve updated the script to handle the new filename and hash, so just the script and rerun it, it should work now.
Note however, that the IOMMU stuff still isn’t enabled. That will still require some time to get implemented.
Thanks @kakaroto, it’s working again. And like many others I’m very much looking forward to “the IOMMU stuff” being enabled. My Librem has been sitting here waiting to run a fully functional Qubes installation ever since I got it.
Hi. I ran the script on a Librem 13 v2 and all went well. I have since reset the laptop by reinstalling Pure OS. Do I have to run the coreboot script again or do those changes survive reinstallation of the OS? Thanks.
Alright so lets assume for a second that running the core boot build script in my situation is not possible. Is there currently a mechanism I can employ to obtain a pre-built image for my Librem 15 v3 which I can just flash on my own? I see there is a coreboot updater purism git repo but it indicates that it is only meant for the Librem 13 v1 so…
My primary goal is to update my firmware/coreboot so that Intel ME is toast. For the time being I’m fine with either using an image to get there or being able to build it myself.
Any suggestions or pointers would be most appreciated, thanks!
I’m running into this issue on my Librem 13v2 as well. I’m also running Arch, so it might be worth revisiting whether that is the cause.
Built purism/librem13v2 (Librem 13 v2)
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)
Cloning into 'me_cleaner'...
remote: Counting objects: 217, done.
remote: Compressing objects: 100% (128/128), done.
remote: Total 217 (delta 126), reused 157 (delta 89)
Receiving objects: 100% (217/217), 68.56 KiB | 403.00 KiB/s, done.
Resolving deltas: 100% (126/126), done.
Note: checking out 'origin/extra_partitions'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
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
EDIT: This is because some of me_cleaner.py is incompatible with Python 3, which Arch uses by default – see this thread for details. Until this is fixed, a temporary workaround is to hardcode me_cleaner.py to use Python 2 instead.
Worked perfectly for me. I’m now Intel ME free! Thanks aarmea! Hopefully the purism maintainer can get this python 2/3 glitch worked out in short order.
@jaylittle@aarmea great to know you got it working. I saw the other thread about it and already answered there.
I’ll just answer your mention of the updater script. That script needs to be updated to work with the skylake machines, unfortunately, I don’t have time to handle it right now, which is why it’s not done yet. Either way, we can’t just distribute the image because of licensing issues, so the script would still need to create the resulting coreboot image then run me_cleaner on it, so in your specific case, it wouldn’t have helped since the error was with me_cleaner.
I’m a bit of a newbie, however I managed to run the script on a Librem 13v2. It completed without any errors and the hash matched, so it offered me to flash, which I did.
My question is: is this the output I should expect after flashing / rebooting? (Flashed November 7th):
~/coreboot/util/cbmem$ sudo ./cbmem -c | grep ^ME
ME: FW Partition Table : BAD
ME: Bringup Loader Failure : YES
ME: Firmware Init Complete : YES
ME: Manufacturing Mode : YES
ME: Boot Options Present : YES
ME: Update In Progress : YES
ME: D3 Support : YES
ME: D0i3 Support : YES
ME: Low Power State Enabled : YES
ME: Power Gated : YES
ME: CPU Replaced : YES
ME: CPU Replacement Valid : YES
ME: Current Working State : Unknown (15)
ME: Current Operation State : M0 without UMA but with error
ME: Current Operation Mode : M0 without UMA
ME: Error Code : Preboot
ME: Progress Phase :
ME: Power Management Event : CM0PG->CM0
ME: Progress Phase State : Unknown phase: 0x0f state: 0xff
ME: Power Down Mitigation : YES
ME: PD Mitigation State : Issue Detected but not Recovered
ME: Encryption Key Override : Workaround Applied
ME: Encryption Key Check : FAIL
ME: PCH Configuration Info : Changed
ME: Firmware SKU : Unknown (0x7)
ME: FPF status : fused
@tez: Yep, that’s perfect, it says YES everywhere and partition is BAD because the status is 0xFFFFFFFF because the ME is disabled and even coreboot can’t get the status.
EDIT: I saw you elsewhere wondering if it’s right because previous comments and @mladen posted a different expected output. Well, that’s because those posts are older, and when they were posted, the ME was only neutralized. The ‘ME disabled’ is newer and gives a different output, as you can see. Yours is the correct/expected output for a disabled ME.
It should be “cbmem” not “./cbmem”, and if you’re on PureOS, make sure you first apt-get install coreboot-utils. Otherwise, you need to grab cbmem from the coreboot/utils/cbmem source directory and compile it.
I have no idea what you mean about BusyBox…
I did a quick review and you don’t do any error handling and your interpreter is wrong. It should be /usr/bin/env bash as /bin/bash is not guaranteed to exist.
Many of the variable references are not double quoted when they should be.
Don’t feel discouraged, however. Apparently people are happy with it, so doing something is better than doing nothing. It’s just that it could be written in a more portable way.
My Librem has been sitting here waiting to run a fully functional Qubes installation ever since I got it.