corna
Adding soft-disable support for IFWI/ME12
Based on the work of @davidmartinzeus
IMPORTANT: If you are new here, please read my comment at https://github.com/corna/me_cleaner/pull/282#issuecomment-992988892
On Intel Cannonlake H (300) Series chipsets such as QM370, Q370, B360, H370, H310, Z390, C242, C246, HM370, CM246 and QMS380 with Intel ME 12, the High Assurance Platform bit has been moved to PCHSTRP32.
My testing board is an ASROCK H370M-ITX/ac. With this patch, I get the usual good signs of ME disablement. ME disappeared from the PCI bus and the OEM bios shows ME version 0.0.0.0.
This patch is the very definition of bare minimum. A proper implementation would consist of parsing the CSE Partition Layout Table to locate the Boot Partition Descriptor Table and then finding a type 2 entry (FTPR). (Like how @platomav 's wonderful MEAnalyzer does)
Other than that, we would probably benefit from a cleaner way of tracking the HAP bit and matching that to specific chipsets. I think the best option there involves parsing the MFS and checking the "008"/"Home Directory" partition's "bup/bup_sku/plat_n_sku", which holds an SKU identifier inside the BIOS image. My current understanding is that any SKU identifier corresponds to a set PCH strap layout and hence a HAP bit position in the rom.
I can confirm that this works on Clevo/Sager P95XER series notebooks (Tested with a P955ER) with ME12.
Original BIOS backup (using Intel FPT)
python ./me_cleaner.py -c ORIGINAL_BIOS.bin
Full image detected
Found FPT header at 0x2000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x88000 to 0x88000
Found FTPR manifest at 0x88250
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is NOT SET
Checking the FTPR RSA signature... VALID
Applying me_cleaner with this pull request #282
python ./me_cleaner.py -s -O PATCHED_BIOS.bin ORIGINAL_BIOS.bin
Full image detected
Found FPT header at 0x2000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x88000 to 0x88000
Found FTPR manifest at 0x88250
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is NOT SET
Setting the HAP bit in PCHSTRP32 to disable Intel ME...
Checking the FTPR RSA signature... VALID
Done! Good luck!
Backup after flashing me_cleaner patched BIOS (patched BIOS flashed using Intel FPT, backup using Intel FPT)
python ./me_cleaner.py -c NEW_BACKUP.bin
Full image detected
Found FPT header at 0x2000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x88000 to 0x88000
Found FTPR manifest at 0x88250
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is SET
Checking the FTPR RSA signature... VALID
Output of Intel CSME MEInfo after flashing me_cleaner patched BIOS
sudo ./MEInfo
Intel (R) MEInfo Version: 12.0.40.1433
Copyright (C) 2005 - 2019, Intel Corporation. All rights reserved.
Error 198: ME disabled.
Per https://github.com/corna/me_cleaner/issues/3#issuecomment-554487267, this PR was required and works fine for me on a Coffee Lake system.
Hi!
I have a brand new Lenovo E490 with ME 12.0.1427.35
- Whiskey Lake
- i7-8565U
- tested with -s and -s
The bios chip is very easy to access. So i have created a dump with flashrom.
After flashing the patched image. lspci shows:
- 00:16.0 Communication controller: Intel Corporation Device (rev 30) 0x9de0
Intelmetool say on the first device 0x9de0:
MEI found: [8086:9de0] Device 9de0
ME Status : 0xa0000245
ME Status 2 : 0xf10506
ME: FW Partition Table : OK
ME: Bringup Loader Failure : NO
ME: Firmware Init Complete : YES
ME: Manufacturing Mode : NO
ME: Boot Options Present : NO
ME: Update In Progress : NO
ME: Current Working State : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode : Normal
ME: Error Code : No Error
ME: Progress Phase : ROM Phase
ME: Power Management Event : Clean Moff->Mx wake
ME: Progress Phase State : (null)
ME: Extend Register not valid
ME: Firmware Version 12.0.1427.35 (code) 12.0.1427.35 (recovery) 12.0.1427.35 (fitc)
ME Capability: Full Network manageability : OFF
ME Capability: Regular Network manageability : OFF
ME Capability: Manageability : OFF
ME Capability: Small business technology : OFF
ME Capability: Level III manageability : OFF
ME Capability: IntelR Anti-Theft (AT) : OFF
ME Capability: IntelR Capability Licensing Service (CLS) : ON
ME Capability: IntelR Power Sharing Technology (MPC) : OFF
ME Capability: ICC Over Clocking : OFF
ME Capability: Protected Audio Video Path (PAVP) : ON
ME Capability: IPV6 : OFF
ME Capability: KVM Remote Control (KVM) : OFF
ME Capability: Outbreak Containment Heuristic (OCH) : OFF
ME Capability: Virtual LAN (VLAN) : ON
ME Capability: TLS : OFF
ME Capability: Wireless LAN (WLAN) : OFF
Laptop is working normaly, no shutdown after 30 mins.
I think, ME12 is ignoring the HAP Bit.
Hi @roema ! :) I think it is unlikely that any ME versions lack the HAP bit behaviour. I'm suspecting that the Whiskey Lake PCH layout is different. Can you send me your original BIOS dump?
@roema Okay, I see what happened here :)
This is the Cannonlake LP variant with a different PCH strap layout. Fixing this in the general case will take some more work, but for now, we can work around this. Try this version. I'm glad if you find my contributions useful :tada:
@dt-zero you are the best! It seems to be working!
Now the device /dev/eim0 is gone and in UEFI BIOS no ME Version shown.
Thank you very much!
This works on MSI B360 Gaming plus as well. I used the me_cleaner.py file from this pull request's commit.
The one posted as a text file did not work (it reported success using me_cleaner.py -c, but when flashed did not neutralize the me)
@beaker23 Glad to hear it works for you as well!
For future reference, there is Cannonlake-H series ( QM370, Q370, B360, H370, H310, Z390, C242, C246, HM370, CM246, QMS380) and Cannonlake-LP. I'm not sure which chipsets are in LP, but generally, if you have ME 12 and its not one of the H series I listed, it is probably LP. The script from the commit is for H series, the one I attached is for LP. Making one script that is compatible with both would involve (like the original message mentions) parsing the ME file system to identify the SKU or something similar. I'm not sure to what extent @corna would like to see me_cleaner modified to accommodate this so I tried to make my changes as small as possible. (Which has its ups and downs as you can see)
Hello @dt-zero, the me_cleaner.py for LP variant of cannonlake you posted is identical to the one from the commit, is there some kind of mix-up there ? The commit variant did nothing for me, I have the LP variant.
On another note since you seem pretty knowledgeable, what can you say about the "Temporarily disable" mode of ME ? It's an hidden option in my BIOS that I can enable and makes ME totally disappear from the PCI bus and no tool can interact with it afterwards , it's doing more than HAP/AltMeDisable on my desktop computer it seems.
Hi @suut , there is a difference between the two, its the offset in the PCH strap region. LP is offset 0x70, while Cannonlake-H is 0x80. If you have an LP board, use the python script I attached. (Not the one from the commit)
Functionality wise, the HAP bit does the same. If you successfully enable the HAP bit, the ME disappears from the PCI bus and no tool will be able to interact with it.
Hi @suut , there is a difference between the two, its the offset in the PCH strap region. LP is offset 0x70, while Cannonlake-H is 0x80. If you have an LP board, use the python script I attached. (Not the one from the commit)
Functionality wise, the HAP bit does the same. If you successfully enable the HAP bit, the ME disappears from the PCI bus and no tool will be able to interact with it.
I meant the two files were byte-for-byte equal but I guess I mixed up downloads, thank you for your feedback, I will try again now.
On another note, how did you find the offset ? Using Intel FIT, toggling the "Reserved" setting and looking at which offset in the image the bit was toggled ? So like at byte 371 for Cannonlake-LP
I meant the two files were byte-for-byte equal but I guess I mixed up downloads, thank you for your feedback, I will try again now.
On another note, how did you find the offset ? Using Intel FIT, toggling the "Reserved" setting and looking at which offset in the image the bit was toggled ? So like at byte 371 for Cannonlake-LP
They are definitely not equal byte-for-byte or otherwise.
My understanding is that Intel (CS)ME System Tools (which include FIT) are not publicly released to end-users but only to OEMs, so naturally I would not try obtain them in any way.
However, purely theoretically, had someone done that, they could extract the platform descriptor XMLs from FIT and use grep to find a sequence of entries that had the same distribution of bits between fields as with Intel ME 11. That way, they could find out that the old entry that used to be called "reserve_hap" is now "PCH_Strap_CSME_CSE_CSME_Reserved". The same xml node would specify the offset and which bit of that entry controls the HAP mode.
I meant the two files were byte-for-byte equal but I guess I mixed up downloads, thank you for your feedback, I will try again now. On another note, how did you find the offset ? Using Intel FIT, toggling the "Reserved" setting and looking at which offset in the image the bit was toggled ? So like at byte 371 for Cannonlake-LP So They are definitely not equal byte-for-byte or otherwise.
My understanding is that Intel (CS)ME System Tools (which include FIT) are not publicly released to end-users but only to OEMs, so naturally I would not try obtain them in any way.
However, purely theoretically, had someone done that, they could extract the platform descriptor XMLs from FIT and use grep to find a sequence of entries that had the same distribution of bits between fields as with Intel ME 11. That way, they could find out that the old entry that used to be called "reserve_hap" is now "PCH_Strap_CSME_CSE_CSME_Reserved". The same xml node would specify the offset and which bit of that entry controls the HAP mode.
Oh I see, thanks for the information !
So for other people interested by some googling we can find cnp_h_rvp.xml and cnp_lp_rvp.xml which contain the PCH straps for Cannonlake H and Cannonlake LP respectively. (I don't know if these documents are too touchy to link in here, feel free to tell me if I need to edit)
@dt-zero Success! This worked on my Dell 7060 MFF (Intel Q370 / Cannon Lake). Dumped the bios via FPT, cleaned it with your me_cleaner patch using the -s for HAP bit enable, flashed it back and it works. There's no info in the BIOS about ME, but Linux can't find anything about it using Intel and other tools, even with the mei kernel modules loaded.
sudo ./intelmetool -d -m
ME PCI device is hidden
RCBA addr: 0x00000000
Can't find ME PCI device
There's no ME device on lspci, and me_cleaner -c says:
Full image detected
Found FPT header at 0x4000
Found 7 partition(s)
Found FTPR header: FTPR partition spans from 0x168000 to 0x168000
Found FTPR manifest at 0x168268
ME/TXE firmware version 12.0.40.1433 (generation 4)
Public key match: Intel ME, firmware versions 12.x.x.x
The HAP bit is SET
Checking the FTPR RSA signature... VALID
I tried deactivating the hap bit on the asus ws z390 pro but no luck. I get an infinite boot loop. I also tried differently recreating the bios using others tools with hap bit on, same result.
Tried this on my machine - sound doesn't work and it takes over a minute to boot ... is this the intended outcome?
EDIT: Is it possible that ME 12 could be supported by whitelisting some more of the modules?
Intel (R) Firmware Update Utility Version: 12.0.65.1567
Copyright (C) 2005 - 2020, Intel Corporation. All rights reserved.
Checking firmware parameters...
Warning: Do not exit the process or power off the machine before the firmware update process ends.
Error 509: Mandatory partitions (FTPR / NFTP / RBEP) were not found in the Update Image.
Hey thanks for this fix, not sure if it's working correctly but I'll leave the terminal details below:
Full image detected
Found FPT header at 0x280000
Found 9 partition(s)
Found FTPR header: FTPR partition spans from 0x26000 to 0x26000
Found FTPR manifest at 0x26238
ME/TXE firmware version 14.0.34.1139 (generation 3)
WARNING Unknown public key 8e4f834644da2bef03039d69d41ecf02
Assuming Intel ME
Please report this warning to the project's maintainer!
The HAP bit is NOT SET
Checking the FTPR RSA signature... VALID
My Motherboard is: MSI MPG Z490 GAMING PLUS LGA 1200 Intel Z490 SATA 6Gb/s ATX Intel Motherboard
The SPI Flash ROM chip I'm working with: MX25L25673G
Also, upon trying to remove the ME section, I am getting this output:
Full image detected
Found FPT header at 0x280000
Found 9 partition(s)
Found FTPR header: FTPR partition spans from 0x26000 to 0x26000
Found FTPR manifest at 0x26238
ME/TXE firmware version 14.0.34.1139 (generation 3)
WARNING Unknown public key 8e4f834644da2bef03039d69d41ecf02
Assuming Intel ME
Please report this warning to the project's maintainer!
The HAP bit is NOT SET
Reading partitions list...
PSVN (0x00000f00 - 0x000001000, 0x00000100 total bytes): removed
UEP (0x0006c000 - 0x00006e000, 0x00002000 total bytes): removed
IVBP (0x00001000 - 0x000005000, 0x00004000 total bytes): removed
MFS (0x00005000 - 0x000069000, 0x00064000 total bytes): removed
UTOK (0x00069000 - 0x00006b000, 0x00002000 total bytes): removed
HVMP (0x00000ec0 - 0x000000ecc, 0x0000000c total bytes): removed
RSTR (0x00000e80 - 0x000000e98, 0x00000018 total bytes): removed
FLOG (0x0006b000 - 0x00006c000, 0x00001000 total bytes): removed
IMDP (0x00000e40 - 0x000000e80, 0x00000040 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xbf)...
Reading FTPR modules list...
Traceback (most recent call last):
File "me_cleaner/me_cleaner.py", line 876, in <module>
check_and_remove_modules_gen3(mef, me_end,
File "me_cleaner/me_cleaner.py", line 422, in check_and_remove_modules_gen3
name = data[0x0:0xc].rstrip(b"\x00").decode("ascii")
UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)
@MattBJ I fixed it for your version, attached below.
Run it with python me_cleaner.py -s orig.bin -O cleaned.bin
@dt-zero Thanks so much!! I'll have to run diff to see exactly what you fixed!
@MattBJ the PCH strap configuration is different for all these platforms, that's what I'm changing most of the time, however in your case I also added the ME14 public key to the list, just to clear the associated warning. Let me know if you achieve the desired results, cheers! :smiley:
@dt-zero I believe it worked perfectly, the modification definitely let me write the cleaned binary file. When I wrote it back to my chip it verified the success, but I won't be able to check if the configuration works until I get my PC tower in a few days (I have everything else). So fingers crossed this works! I really appreciate your work, and everybody else's here.
If I wanted to neutralize and shrink the ME section of the ROM, would I just do this: python me_cleaner.py -S -r -t -d -O out.bin -D ifd_shrinked.bin -M me_shrinked.bin original_dump.bin According to the neutralize and shrink section of https://github.com/corna/me_cleaner/wiki/External-flashing Or would it somehow be different with your updated version? I'm guessing not. Also, if you happened to know, what would be the general purpose of shrinking this portion? And, also, when getting bios updates, will I always have to scrub out the ME or will that piece be unaffected throughout the life of the motherboard unless I decide to revert to my saved original copies?
Once again thank you for your time!
@MattBJ
So fingers crossed this works! I really appreciate your work, and everybody else's here.
Awesome, good luck!
If I wanted to neutralize and shrink the ME section of the ROM, would I just do this:
Changing the layout of the rom, such as shrinking or deleting partitions is not supported since the IFWI format (starting from ME12) was introduced. The original script here only allowed you to do that, because it didn't recognize ME 14, since I only hardcoded that check for ME12. (Which was the latest version when I wrote that code) So no shrinking or deleting partitions, unless you add support yourself, sorry :frowning_face:
Also, if you happened to know, what would be the general purpose of shrinking this portion?
As far as I'm aware, the purpose of shrinking, would probably be to gain more usable space on the BIOS chip, which would come handy in case of using a custom BIOS like Coreboot. I wouldn't worry about that with the OEM bios.
And, also, when getting bios updates, will I always have to scrub out the ME or will that piece be unaffected throughout the life of the motherboard unless I decide to revert to my saved original copies?
BIOS updates will restore the flash's content, so you will have to do this procedure every time you update your BIOS.
Once again thank you for your time!
You're welcome, I'm glad people are showing interest in this, so at least on paper Intel has some incentives to fix their crap.
@dt-zero
Confirmed working on a Lenovo Yoga X390 20NN00F8GE with ME 12.0.35.1427 (Cannonlake-LP). Attached a CH341A programmer to the BIOS chip next to the PCIe SSD (a 256MBit MXIC MX25l25673G that flashrom recognized as MX25L25635F/MX25L25645G, though it handled the IC without a hitch). Binary diff shows that me_cleaner set the bit 0 at address 0x173 (from 0x18 to 0x19), otherwise the dumps before and after are equal.
ME Version in BIOS setup is gone, as well as /dev/mei0. Great success! I noticed two things though.
- I did several BIOS updates (1.69 -> 1.72 -> 1.74 -> 1.76) and the HAP bit was not reset in any of them. Apparently the Lenovo BIOS update scenario does not handle it.
- There is a concerning power drain when the machine is off (about 10% per day). This happens only after setting the HAP bit. Not a big concern for me as I mainly use the machine with power sockets in reach, though I worry a little for battery degradation. Maybe it has something to do with the PMIC? Did you guys measure power consumption when your machines are off?
Anyway, I would like to thank you for the time that you invested into me_cleaner for handling ME12. Do you think the recent Intel leaks could advance this project further? Is there even still interest in this? The last commit dates back to 2018...
@MattBJ and @dt-zero are you or anyone else able to confirm whether setting the High Assurance Platform bit and soft-disabling the ME still works on platforms with ME versions above version 12?
Thanks for your work, @dt-zero I tried using it to remove ME 12 on my nuc8 (i5-8259U, coffee lake).
Unfortunately, ME is still present after flashing the rom with the HAP bit set.
Could you have a look at what is going wrong here?
https://github.com/Yannik/nuc8-firmware/raw/main/orig.rom https://github.com/Yannik/nuc8-firmware/raw/main/hap-bit-set.rom
Hi @Yannik
You got the LP series variant, same case as @roema . I attached your rom with the HAP bit set. hap_set.zip
For future reference, you can use the modified script I linked in my previous answer: https://github.com/corna/me_cleaner/pull/282#issuecomment-554627204