After reading the research done by Trammell Hudson, Nicola Corna, Federico Amedeo Izzo and other members of the open source firmware initiatives, I decided to do some tests on an ASRock P55 Extreme system which comes with Intel ME 6.0 Ignition firmware.

Ibex Peak PCH came with four different Intel ME SKUs: Ignition (144KB - 148KB), Consumer 1.5MB, Corporate 5MB Desktop and Corporate 5MB Mobile. The Ignition SKU was the most cut down as far as functionality is concerned focusing mostly on clock control & power management. It is the only SKU that does not expose an OS communication device (MEI) no matter its state or health.

Testing the Ignition SKU is interesting because it's the only one which is designed/allowed to work without any firmware. That is because, on such Ibex Peak PCH, the ME co-processor is only used to support Ignition firmware features and nothing else. These features are four: Platform Clock Configuration (PCC), Platform Feature Configuration (PFC), Silicon Workaround Capability (SWC), & Thermal Reporting (TR). Some are only relevant/useful to OEMs to reduce factory time and money spent on part acquisition/replacement (OEM) and don't necessarily translate to actual consumer use/benefit (USER). PCC deals with EMI management/control, power management and allows using the same firmware across many boards (OEM). PFC enables automatic setting of platform specific values based on detected hardware such PCH support for ECC memory, CPU support of onboard iGPU, supported PCI Express Graphics lane width etc (OEM). SWC can resolve some specific types of post-Production silicon issues which would otherwise require a new PCH or CPU stepping (USER). TR makes thermal and power information from CPU, GPU, RAM & PCH available to the host or EC (OEM). From these four Ignition features, only SWC is irreplaceable from other open source or not firmware solutions. PCC seems purely an OEM assistance feature and PFC as well as TR can probably be implemented in BIOS.

The Ignition firmware does not run corrupted Code or Data. When the platform starts, the ME executes from the Internal PCH ROM and checks the integrity of the Ignition Runtime partition (IGRT). If IGRT checks out, the ME loads it and uses that instead of the internal ROM in order to verify the integrity of the IGRT Data partition (FAD0). If that checks out, the ME has found proper Code & Data partitions so it executes PCC, PFC, SWC & TR before giving control to the BIOS. If the IGRT integrity check fails, the Internal ROM checks the integrity of the Factory Recovery Partition (FTPR), uses it if proper, checks the integrity of FTPR Data partition (FAD1) and if they are both ok, it executes the four Ignition features and gives control to BIOS. If IGRT Code fails and then FTPR Code partition fails, the ME cannot find proper Code & Data partitions so the platform resets and starts again with ME disabled. The same happens if IGRT checks out but both IGRT and FTPR Data partitions do not at the next stage. With Ignition disabled, the system is supposed to boot properly but without PCC (stock hard-coded PCH clocks used, no power/EMI management, no board specific config), PFC (defaults used: iGPU on, ECC on, PCIE x16), SWC and TR.

So it seems that disabling & removing the ME 6.0 Ignition firmware from the SPI chip completely is very much possible. As a baseline, meaning when the Engine firmware is operating properly, we see the following status at Intel MEInfo tool:



The ME has loaded Runtime Code (IGRT) and Runtime Data (FAD0) partitions. The ICC is configured, any PCH/CPU silicon issues are resolved (SWC) and no TR or similar events are reported.

First, I tried Corna's me_cleaner (no LZMA modules at Ignition SKU, only Huffman) and it worked.




Then I nullified/padded (0xFF) the entire 128KB ME Ignition region. That basically removes the entire contents of the ME firmware from the SPI chip. Again, it worked.



The next step would be to remove the ME Region from the SPI image entirely and also adjust the Flash Descriptor to have the ME disabled and thus gain some space at the BIOS. So, I removed the ME base and limit from the FD and adjusted the BIOS to fill the rest of the SPI chip. For my 2MB SPI chip, that meant 0x1000 for the FD and 0x1FF000 for the BIOS. It works.



Now for some finishing touches, I removed the ME VSCC table entries from the FD (the ME should not be able to communicate properly with the SPI) & disabled the ME SMBus. Possibly more can be done at the FD (although there might be no point anymore) by reading what certain FITC values do at Intel's BringUp Guide for ME6 if you can find such a document online. It works and after all these tests, the system stays operational even after the 30 minute obligatory shutdown (which is not used for the Ignition SKU firmware).



So it indeed possible to completely disable & remove the ME 6.0 Ignition firmware without any major/apparent issues with the system except those that use the power management, thermal reporting and especially silicon workarounds.

• Note though that these Ibex Peak findings are only relevant to the Ignition SKU and not 1.5MB, 5MB DT or 5MB MB. Such a modification will not work on these three SKUs.
• There are two types of the Ignition SKU, 6.0.x for Ibex Peak (5/34xx-series) and 6.0.50 for Cave/Coleto Creek (89xx-series) PCH. The above have not been tested on the latter PCH, only Ibex Peak. It should allow the same degree of success but, without actual tests, we cannot be certain.

There are no steps, this is not a guide. It's a small observation post, like a "paper" so to speak.

You cannot completely remove ME8, the closest you can get is achieved by me_cleaner.

Read the introduction by corna and if you give it a try, post your result in the status report github issue.

I've added an explanation as to why Ignition was interesting for me to test when it comes to completely removing its firmware. Includes initial Ignition boot flow and usefulness, according to Intel.

I don't know the answer to your question. ME dumps are different because of the DATA (MFS/EFFS) section it has. That section is pre-configured by the OEM but is also adjusted by the ME during normal operation. It gets removed by me_cleaner and thus stock clocks and configuration are used until the ME is repaired.

That is not related to the guide. You need to have read/write access to the Engine region of the SPI in order to reflash the ME firmware. I've explained the various (difficult) ways of during that at other threads. If you have a programmer, use that instead.

This is not really related to this guide. Anyway, what system are we talking about? When it comes to VSCC, they are stored in the Flash Descriptor and you can see such errors only if you replaced the SPI chip with a different one. So did you do that? If you haven't done that, I suggest you follow the [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization on your full SPI dump or the latest full SPI/BIOS from the OEM, if provided. You need to have read/write access to the SPI/BIOS chip or use a hardware programmer.

What is the model of the system that we are talking about so that I can check the OEM provided SPI/BIOS?