Adding soft-disable support for IFWI/ME12 #282
Conversation
Based on the work of @davidmartinzeus
|
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) Applying me_cleaner with this pull request #282 Backup after flashing me_cleaner patched BIOS (patched BIOS flashed using Intel FPT, backup using Intel FPT) Output of Intel CSME MEInfo after flashing me_cleaner patched BIOS |
|
Per #3 (comment), 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
The bios chip is very easy to access. So i have created a dump with flashrom. After flashing the patched image.
Intelmetool say on the first device 0x9de0: |
|
Hi @roema ! :) |
|
@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. |
|
@dt-zero you are the best! 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) |
|
Commit from PR works on Z390M-ITX/AC. |
|
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. |
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. |
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 ME device on lspci, and me_cleaner -c says: |
|
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? |
|
@MattBJ I fixed it for your version, attached below. Run it with |
|
@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! 😃 |
Awesome, good luck!
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)
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.
BIOS updates will restore the flash's content, so you will have to do this procedure every time you update your BIOS.
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. |
|
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.
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... |
|
I can confirm this works tried it on my ROG MAXIMUS XI GENE |
|
@dt-zero Having some trouble using this on an Apollo Lake system (UP Squared), with the ME variant Intel seems to call CSTXE v3. This is an IFWI platform, which I guess explains "The ME region in this image has already been disabled" even though it's a stock image that the ME is clearly working when using. Using me_cleaner from your branch: For what it's worth, the other version you linked in this thread did not work either, though that's to be expected (it's not, as far as I can tell, designed for Apollo Lake, as that's not what the other user's problem was with). I have tried setting the AltMeDisable bit in the flash descriptor with ifdtool, but this (rather expectedly) does not work - the ME is still alive and well, according to intelmetool (the version from this branch, Reddit post links to the GitHub but the GitHub has almost no info about it so linking to the Reddit post, needs to be used on this hardware, the one in coreboot master does not detect the newer ME) and Intel TXEInfo. I hoped to try patching your branch for Apollo Lake myself, and, hypothetically speaking, were I to have extracted the contents of the Intel FIT binary for my TXE version (CSTXE System Tools v3 r12 Flash Image Tool, Linux version) using Positive Technologies notes that Apollo Lake ignores the I have attached the original BIOS dump (a raw, 16MiB whole-chip image), though it is also available from the manufacturer's website. UPDATE: I have noticed that ifdtool has a |
|
@DodoDude700 : You seem to have done your homework regarding what is out there, good job on that. Unfortunately, I have a pretty tough time with this one. In general, I don't see this PCH strap as part of the TXE platforms (Apollo Lake/Broxton/Gemini Lake) so I have no clue about whether or not it really exists for your device. I know this is not what you wanted to hear - sorry. |
|
So, I spent some time talking to the Coreboot developers about this (in the IRC). As it turns out, the Apollo Lake TXE is quite markedly different from the Management Engine's other iterations. For example, to quote developer icon:
and in response to my question about ifdtool in APL quirks mode:
As such, it does not appear that Apollo Lake (and possibly "its relatives", maybe Gemini Lake too?) really have a HAP bit, at least not one icon was aware of or one I could find. However, talking to Coreboot developers did solve one mystery - that of the Management Engine showing up under the stock firmware but not under Coreboot. In the coreboot sources, under On the stock firmware, my intelmetool output (minus the PCI device "debug spam" the exander77 branch outputs): Despite the concerns of some of the devs I spoke to that intelmetool may not handle Apollo Lake properly, on the stock firmware, this looks like a sensible output - we see that the TXE is alive and well in a normal state, that it's on firmware version 3.1.2351.75, and that its listed capabilities match what would be expected of the Apollo Lake TXE (while lacking the features of higher-end ME variants which Apollo Lake is not supposed to support. It should also be noted that these results agree with what Intel's own TXEinfo, which definitely DOES support Apollo Lake properly, says when run on the same machine. As such, I'm willing to consider intelmetool, at least this branch, a relatively decent way to determine TXE state on Apollo Lake. Now here comes the weird part: under Coreboot, even without any kind of HAP/AltMeDisable bit set, and even with no modifcations to the ME firmware built into the Coreboot image's IFWI, intelmetool gives me this: This is extremely interesting. The Management Engine appears to be in an intermediate, "half-disabled" state. As with me_cleaner'd firmware, we see we see Firmware Init Complete at We can also see that, whereas the ME is able to return its firmware version to intelmetool under the stock firmware, here that times out and causes intelmetool to exit. Patching out the firmware version check, we get a similar error in its place when it attempts to check capabilities: Seeing this, I very much expected the 30 minute watchdog to reset the machine, as the ME is clearly in a bad state, and this is not a state I have seen documented with any technique to disable the ME, so I did not expect it to work around the watchdog. However, I have left the machine running for hours in this state and it appears stable and reliable. As such, it appears that Coreboot on this hardware has somehow broken the Management Engine/TXE firmware or forced it into recovery mode, preventing it from initializing properly but somehow either also breaking the watchdog timer or remaining alive enough to reset it. I thought that Intel's own TXEinfo may be more enlightening about the TXE's state, but it fails with this: As such, I conclude that:
For my purposes, I think I'm now comfortable concluding that the Management Engine on this board is essentially disabled, albeit in a different state than other ME disable methods, which does not appear to have been documented before. Further research into this may be useful. |
|
Hello, I need a help regarding the following issue. I Have an Asus Z590-A motherboard with intel i7 11700k and intel Me 15.0.1466. here I attach the bios dump. Thanks in advance. |
|
Hi, can you tell me if it is still possible to enable HAP on 11th gen? |
|
I tired to enable it with |
|
Okay, so since this pull request got a lot of traffic since I opened it, let me say something now. At the same time, my expectation when I opened this pull request was that it may or may not be merged but that it's going to be a reference point for @corna to help with the maintenance of the project. Since then, this grew to the size that it's taking up significant chunks of my time to keep supporting each and every one of you who reaches out on github or via email. I did this research on my own time but otherwise I'm full time working for a company (Zero IT Lab) that requires me to do a ton of other stuff during the daytime. It's becoming hard to balance that and it's unsustainable for me to dedicate significant free time to keep up with this. I'll try to answer this set of questions that piled up until now (in my next comment), but please don't "expect" my support. Realistically speaking, since the project seems abandoned by corna, it's probably time for a fork/rewrite. It could be a company project for us, if there was financial backing to do it at reasonable market rates; but that kind of interest does not seem to be there. From my experience, most of the people who reach out to me are private individuals who do this for the enthusiastic/educational aspect. (and therefore don't want to/can't afford that kind of backing) |
|
@joex2021 The HAP offset for your rom is 0x196. 0x0 = Hap disabled; 0x1 = Hap enabled.
It will edit the file ("z590_copied.bin") in place and enable the HAP bit. Flash and you should be good. (No guarantees) @helios-chad Yes, it is possible. As I showed above, we are still enabling the HAP bit on ME 15 which is more up to date. I haven't had any issues as long as you are on a consumer (CSME) platform and not TXE like @DodoDude700. |
|
@dt-zero thank you for trying help us here, I understand all what you wrote and I totally agree with you. Thank you for your help and patience. |
|
@joex2021 You are welcome. What I wrote is a command you can execute under a linux terminal environment to edit the BIOS rom, no special tool needed. (just paste into a terminal) |
|
@dt-zero Thanks again for the help. Unfortunately I couldn't test your method, I had to return that motherboard due to VRM heating problem, I ordred an Asus Z590-P instead. I will try the suggested solution when it arrives and I will report the result here. |
just dropping in to say this modified me_cleaner.py script also worked like a charm on my z490 board (once I built flashrom from the latest dev build to be able to recognize the chip) thankyou @dt-zero ! |
|
Pull #282 works flawless on a Clevo N350TW (Schenker Dock 15 L2018). BIOS Menu shows IME FW version 0.0.0.0. No more HECI present on the PCI bus. No problems so far with Linux. Even suspend and the docking station works fine. |
|
@dt-zero the modified me_cleaner.py doesn't work for me. my pc just bootloops with the py file in this PR, and that py file boots but doesn't disable ME: NOTE: UEFI also correctly gives the ME firmware version. Here's my firmware bins (orig.bin and cleaned.bin) Board: MSI-Z390-A Pro |
|
@Absolucy quick diff check shows I set it for you using dd anyway (didnt bother with anything else) also has anyone tried setting it on an alder lake board? im considering buying a new pc soon and id like to know if it still works. i'm assuming it does (in one way or another) given its original intended purpose, although with every new platform it could always change. if anyone would be willing to test or upload a dump of their rom id be interested to take a look edit: |
|
@ritalinaddict Original script just bootloops... |
|
@Absolucy well try using the rom I posted, it should work fine |
|
@ritalinaddict thanks for your Alder Lake suggestion. I tried it on an MSI PRO Z690-A DDR4 motherboard, using version 120 but unfortunately it boot loops. I might be doing something stupid, so I'll list the steps I took:
|
|
Greetings to all chat participants concerned about cleaning Intel ME. Details and Details… It has been working fine for 2 weeks. There is an assumption that it is necessary to reset the newly stitched BIOS to the standard settings before updating Intel ME, while it may not faint so deeply when flashing Intel ME. Anyone who wishes can try and unsubscribe.RUS Приветствую всех участников чата, озабоченных очисткой Intel ME. Детали и подробности… Уже 2 недели работает нормально. Существует предположение, что нужно перед обновлением Intel ME сбросить только что прошитый БИОС к стандартным настройкам, при этом может не упадёт в обморок настолько глубоко при прошивке Intel ME. Кто желает, может попробовать и отписаться. |
Sources: corna/me_cleaner#282 (comment) and https://github.com/corna/me_cleaner
|
Many thanks to @dt-zero for the modified version, I tried it on my 8th gen NUC and it worked great. I wrote a guide explaining how to do this: How to Disable IME on Intel NUCs. If you don't mind, I also forked your modified version in my guide. |
|
Szia @dt-zero, I tried to use me_cleaner.py and flashed the cleaned ROM in my MSI Godlike Z390 motherboard to use with i9-9900K but BIOS still shows ME version. Guess, I couldn't do it properly. I would be grateful if you could look into my BIOS dump and provide a ME disabled version. |
I'm also getting bootloop continuously even with correct HAP bit set manually using The way I get my board back working is to switch to another BIOS using the hardware BIOS switch and flash the OEM version to the other chip. Any help from someone would be awesome. |
Unfortunately we won't get any more help, this project is simply dead. but there is still hope ;-). There is another method that worked for me on my Z590 and 11 gen CPU. Just read the research made by Positive Technologies and you will be able to disable it permanently and it will stay disabled even after performing BIOS updates . Good luck. |
|
Greetings to all free IT specialists, participants of this branch. I respect people trying to get rid of corporate bookmarks. I myself 3 months ago with the help of your branch got rid of Intel.me , I wrote about it above and I want to share my impressions of it. What has clearly changed is that the reaction to cookies has become somewhat different. Before removing the ME for the computer, there were no problems determining my location for websites and stores, now 50% does not guess. Gaivoronsky B.Yu. RUS… Я уважаю людей старающихся избавится от закладок корпораций. Я сам 3 месяца назад с помощью вашей ветки избавился от Intel.me, я писал об этом выше и хочу поделиться впечатлениями от этого. Явно изменилось то, что реакция на куки стала несколько иной. До удаления МЕ для компьютера не было проблем определить моё местоположение для сайтов и магазинов, сейчас в 50% не угадывает. Гайворонский Б.Ю. |
When CSME is 'cleaned' (whether with the HAP bit or by removing components), the HECI interface is disabled. This measurably increases the boot time, as the FSP retries the requests. Therefore, disable these retries (which cannot succeed) to decrease the boot time. Note that while this may be applicable to Cannonlake as well (see corna/me_cleaner#282), me_cleaner is not supported in coreboot beyond Kabylake. Tested on an out-of-tree Acer Aspire VN7-572G, boot time does not measurably increase when CSME is disabled by setting the HAP bit. Change-Id: Ibaf0cfb5e1ed7438f9b8f7e348e314a667ecbcc5 Signed-off-by: Benjamin Doron <[email protected]>
|
Приветствую всех свободных айтишников, участников этой работы. Я уважаю людей старающихся избавится от закладок корпораций. Я сам 3 месяца назад с помощью этой ветки #282 избавился от Intel.me, я писал об этом там выше и хочу поделиться впечатлениями от этого. Явно изменилось то, что реакция на куки стала несколько иной. До удаления МЕ для компьютера не было проблем определить моё местоположение для сайтов и магазинов, сейчас в 50% не угадывает. Немного изменилось поведение ОС в отношении электропитания. При каждом выходе в спящий режим в системный журнал записывается ошибка с кодом 137 «Встроенное ПО системы изменило регистры диапазона типа памяти процессора (MTRR) при переходе в спящий режим (S4). Это может замедлить возобновление работы.» – эта ошибка описана не очень хорошо, поэтому не уверен на 100% что она именно из-за удаления МЕ. |
Based on the work of @davidmartinzeus
IMPORTANT: If you are new here, please read my comment at #282 (comment)