

The Intel Management Engine ('IME' or 'ME') is an out-of-band co-processor integrated in all post-2006 Intel-CPU-based PCs. It has full network and memory access and runs proprietary, signed, closed-source software at ring -3,[1][2][3][4] independently of the BIOS, main CPU and platform operating system[5][6] — a fact which many regard as an unacceptable security risk (particularly given that at least one remotely exploitable security hole has already been reported[7][8][9]).

In this mini-guide, I'll run through the process of disabling the IME on your target PC.[10] To do so, we will use Nicola Corna's me_cleaner. This software operates on the firmware stored in your PC's BIOS chip (where the bulk of the ME's code resides), and does two things:

sets the 'High Assurance Program' bit, an ME 'kill switch' that the US government reportedly [11] had incorporated for PCs used in sensitive applications [12] [13] ;

had incorporated for PCs used in sensitive applications ; removes the vast majority of the ME's software modules (including network stack, RTOS and Java VM), leaving only the essential 'bring up' components (the latter being necessary because, on modern systems, if the IME fails to initialize, either the machine startup will be completely halted at that point, or startup will appear to complete, only for a watchdog timer to reset the whole PC 30 minutes later[14]).

This combined 'belt-and-braces' approach means that the ME ought to cleanly enter a self-induced null state (after resetting the 30-minute watchdog timer) but, should that not work, it will nevertheless enter a failed state shortly thereafter (as the majority of its core software modules have been purged).

Note

You may wonder how this can work at all, given that the ME's code is signed. The reason (fortunately for us) is that the ME's software is deployed as individually signed modules that are signature checked only when loaded — and they are lazy loaded.[15] The very first module, BUP (or 'Bring UP'), contains the watchdog timer reset, and is left alone by me_cleaner . Once BUP has completed, the ME will either enter a 'parked' state (if the HAP/AltMeDisable bit is respected), or try to load the remaining RTOS modules (if not). In the former case, the ME is cleanly disabled. In the latter case, the signature check fails and the ME effectively crashes. Either way, it is out of action from that point. You may wonder how this can work at all, given that the ME's code is signed. The reason (fortunately for us) is that the ME's software is deployed asthat are signature checked only when loaded — and they are lazy loaded.The very first module,(or 'Bring UP'), contains the watchdog timer reset, and is left alone by. Oncehas completed, the ME will either enter a 'parked' state (if the HAP/AltMeDisable bit is respected), or try to load the remaining RTOS modules (if not). In the former case, the ME is cleanly disabled. In the latter case, the signature check fails and the ME effectively crashes. Either way, it is out of action from that point.

Warning

The process involved will require re-flashing your system's BIOS-chip firmware image, and will almost certainly void your system warranty. It may result in your machine becoming 'bricked'. On some (though not many) PCs, the ME is used to initialize or manage certain system peripherals and/or provide silicon workarounds — if that is the case on your target machine, you may lose functionality by disabling it.

Remember: disabling the IME is a completely optional step: proceed entirely at your own risk.

The process we will be following is as follows:

ensuring you have the necessary components available;

locating (and identifying) the BIOS flash chip on your target PC;

setting up a Raspberry Pi 3 Model B (or B+) ('RPi3') or Pi 4 Model B ('RPi4') as an in-system flash programmer;

reading the original firmware from the BIOS flash chip (and validating this), using the RPi3/4;

creating a modified copy of this firmware using me_cleaner ;

; writing the modified copy of the firmware back to your PC's BIOS flash chip, again using the RPi3/4;

restarting your PC, and verifying that the IME has been disabled.

Although some systems do allow the full contents of the BIOS flash chip to be reprogrammed using software tools only (so called 'internal flashing'), on most PCs this facility is either completely unavailable, or can only write to the unprotected areas of the flash filesystem (excluding the ME area), or will only write vendor-signed images. Accordingly, we will describe the approach of using 'external' flashing in this guide, as that is the most reliable.

Warning

Although the most reliable method, external flashing does require you to open the case of your PC, an action that by itself is likely to void the warranty on non-desktop systems. Always observe Although the most reliable method, external flashingrequire you to open the case of your PC, an action that by itself is likely to void the warranty on non-desktop systems. Always observe proper ESD protective measures when working with exposed system boards, and ensure that you have all external power sources and batteries removed. Backup any important files before proceeding. Read all instructions carefully and proceed only if you are comfortable, and at your own risk.

If you are ready, let's go!

Prerequisites

To proceed, you will require the following:

an Intel-CPU-based target PC — that does not have Boot Guard enabled — on which you wish to disable the IME; the target PC may be running an OEM BIOS (such as AMI, Dell etc.), or coreboot;

have Boot Guard enabled — on which you wish to disable the IME; a Raspberry Pi 3 Model B or B+, or Pi 4 Model B single board computer ('RPi3' or 'RPi4'), for use as an external flash programmer;

a spare >= 8GB microSD card (to hold the 64-bit Gentoo O/S image we will use for the RPi3/4);

an appropriate IC clip for your target PC's flash chip, e.g.: a Pomona 5250 for SOIC-8 chips; a Pomona 5208 for unsocketed DIP-8 chips, or a Pomona 5252 for SOIC-16 chips;

8 female-female connector wires (to attach the appropriate clip to the RPi3/4's GPIO header);

a maintenance manual for your target PC, where available, to assist in safe disassembly / reassembly; and whatever tools are stipulated in the above.



Note

AMD-CPU-based systems do not have the IME of course, but do have a broadly equivalent subsystem, the platform security processor (or 'PSP'),[16] for which there is no equivalent workaround at the time of writing. AMD-CPU-based systems do not have the IME of course, buthave a broadly equivalent subsystem, the platform security processor (or 'PSP'),for which there is no equivalent workaround at the time of writing.

Note

Intel systems that have Boot Guard enabled cannot be fully 'cleansed' — this technology stores a public verification key for the vendor's (signed) firmware images in one-time-programmable fuses in the CPU, and utilises the ME to verify these.[4] It was introduced in the 4th generation (Haswell) architecture. By definition, Boot Guard cannot be active on systems where the motherboard and CPU are purchased separately, and at the time of writing only a minority of laptop systems have it active. Note however that you should be able to use me_cleaner 's -s/--soft-disable-only option even if Boot Guard is in use on your system. Intel systems that have Boot Guard enabledbe fully 'cleansed' — this technology stores a public verification key for the vendor's (signed) firmware images in one-time-programmable fuses in the CPU, and utilises the ME to verify these.It was introduced in the 4th generation (Haswell) architecture. By definition, Boot Guardbe active on systems where the motherboard and CPU are purchased separately, and at the time of writing only a minority of laptop systems have it active. Note however that you should be able to use'soptionBoot Guard is in use on your system.

Note

Note that there are many other Note that there are many other SBCs that may be used for in-system flash reprogramming, for example the BeagleBone. You can also use the RPi3/4 in 32-bit mode, and it is also possible to use earlier versions of the RPi. However, for the sake of concreteness, I will assume you are using the specified (RPi3 or RPi4) system in what follows.

Note

Other brands of IC clip are available, but Pomona is arguably the best known, and their model numbers often quoted by 'compatibles'. If you are unsure which type you need, see the Other brands of IC clip are available, but Pomona is arguably the best known, and their model numbers often quoted by 'compatibles'. If you are unsure which type you need, see the next step

Note

Desktop users whose motherboard contains a socketed DIP-8 chip, may use a Desktop users whose motherboard contains aDIP-8 chip, may use a solderless breadboard to hold the flash chip while programming. In such a case, use female-male connecting wires, or use break-away male headers on the breadboard, and connect the female-female wires from the RPi3/4 to those.

In the text, I will run through the process of reflashing the BIOS-chip firmware on a specific machine, namely the long-suffering Panasonic CF-AX3 Ultrabook used in the main body of this guide. This has a SOIC-8 BIOS flash chip, so we will be using a Pomona 5250 clip. Of course, you should adapt the following instructions to match your specific setup, flash chip type etc.

Locating (and Identifying) the Target PC's BIOS Flash Chip

To begin — always observing good ESD practices, and following the instructions given in your target system's maintenance manual — disconnect any external power sources and removable batteries, and then expose your target PC's motherboard.

For desktop machines, gaining access to the motherboard is generally easy, but for laptops the disassembly process is often quite fiddly. However, the Panasonic CF-AX3 is refreshingly straightforward in this regard — after removing the main battery and removing 19 small screws on the bottom-side, the rear panel of the laptop lifts off easily. With this done, a second (internal) li-ion battery must be disconnected, after which the mainboard is ready for inspection. Obviously, the approach required for your system will be different.

Tip

In addition to your manufacturer's maintenance manual, you can also often find useful disassembly videos by searching on YouTube.

Note

It is not generally necessary to remove the small CMOS button battery found on most boards, in order to reprogram the BIOS flash, but your system may differ. Be aware that if you do remove this battery, things like the BIOS password will probably be erased, if you set one earlier ( OpenRC track). It isgenerally necessary to remove the small CMOS button battery found on most boards, in order to reprogram the BIOS flash, but your system may differ. Be aware that if youremove this battery, things like the BIOS password will probably be erased, if you set one earlier ( systemd track

Once you have your target PC's motherboard exposed, locate its BIOS flash chip. On many machines, the BIOS chip will be marked with a sticker or paint dot. Laptops will generally have 8-pin or 16-pin SOIC packages;on desktop machines, 8-pin socketed (and unsocketed) DIP packages are also common.

Note

If your BIOS flash chip is in a If your BIOS flash chip is in a PLCC or WSON package, you will need specialized equipment to connect to the chip, the process for which is not currently covered in this guide.

The CF-AX3 has a SOIC-8 flash IC, as shown:

Location of the SOIC-8 Flash Chip on a Panasonic CF-AX3 Laptop; Pin 1 on Bottom Left

Once you have located the BIOS flash chip, with the help of a magnifying glass (good apps for this are available for IOS and Android phones) or digital camera, read off the maker's name and model number from the device. Then, use a search engine to locate the device's datasheet.

For example, as the above photo shows, the CF-AX3 has a Winbond W25Q64FV IC; its datasheet may be found here. This part uses a very commonly seen pinout, as follows (note how the pins are numbered counter-clockwise):

Pinout of a Typical SOIC-8 / DIP-8 BIOS Flash Chip

Warning

You must always check the pinout and voltage requirements of your particular device, and adapt the connections on the IC clip accordingly. While a large number of 8-pin devices use the layout shown above, not all do.

Note that on DIP packages, the top of the chip will generally be marked by a semicircular indent; on SOIC packages, a small circle or indent will mark pin 1 (NB, do not confuse this with any paint blobs the manufacturer may have used to highlight the flash chip, as for example with the blue paint blob used on the CF-AX3.)

Write down the pinout for your device, if it differs from that shown in the above diagram.

Note

While, following common usage, this guide talks about the 'BIOS chip' and 'reflashing the BIOS firmware' etc., it is important to understand that the BIOS code proper is only one component of the firmware stored on the flash chip. It would be more accurate to talk about it as the 'system firmware flash memory' or similar, containing multiple regions (for the BIOS, IME, Gigabit Ethernet etc.) each of which can contain multiple modules. For more details, please see e.g., John Butterworth's While, following common usage, this guide talks about the 'BIOS chip' and 'reflashing the BIOS firmware' etc., it is important to understand that the BIOS code proper is onlycomponent of the firmware stored on the flash chip. It would be more accurate to talk about it as the 'system firmware flash memory' or similar, containing multiple regions (for the BIOS, IME, Gigabit Ethernet etc.) each of which can contain multiple modules. For more details, please see e.g., John Butterworth's "Introduction to BIOS & SMM" slidesets

Setting up the RPi3/4 as an External Flash Programmer

Next, we will set up a Raspberry Pi 3 Model B / B+ ('RPi3') or Pi 4 Model B ('RPi4') single board computer as an external flash programmer, running 64-bit Gentoo Linux as its operating system. For convenience we will use a pre-built image.

Software Configuration

Download, write and boot the Gentoo image provided here on your RPi3/4 (following the instructions given on that page).

Tip

It is a good idea to write the Gentoo image to a different (spare) microSD card from your main Raspbian system; that way, you can easily revert to using Raspbian when done.

Note

It is of course possible to carry out the flashing procedure described in this chapter using other RPi OSes; however, for concreteness (and since it has all the necessary components available) I will assume you are using the specified It is of course possible to carry out the flashing procedure described in this chapter using other RPi OSes; however, for concreteness (and since it has all the necessary components available) I will assume youusing the specified gentoo-on-rpi-64bit image, in what follows.

The image starts up directly into an Xfce4 desktop, pre-logged in as the demouser account. When the boot has completed, open a terminal window on (or ssh in to) the RPi3/4 and become root:

demouser@pi64 ~ $ sudo su --login root

If you have not modified the default image settings, no password will be required for this step.

Next, note that if you are using version >=1.2.0 of the gentoo-on-rpi3-64bit image, all the required software now comes pre-installed for convenience, so you can skip directly to the "Hardware Configuration" section now. Otherwise, keep reading.

Then, modify the /boot/config.txt file so that the SPI interface (used to communicate with the flash chip) is available via the RPi's GPIO pins. As root, issue:

pi64 ~ # nano -w /boot/config.txt

and modify that file, uncommenting the following line (if not already done):

FILE /boot/config.txt Enable the SPI interface on your RPi

dtparam = spi=on

Leave the rest of the file as-is. Save, and exit nano.

Tip

If you are using the official 7" touchscreen with your RPi3/4, you can also add lcd_rotate=2 to /boot/config.txt , to efficiently rotate the display (and touch region) to match the default orientation of the case. For avoidance of doubt, if you are using a monitor or ssh connection you should not add this stanza, however.

Next, fetch up-to-date copies of the sakaki-tools and genpi64 ebuild repositories ('overlays') on the RPi3/4. Ensure your RPi has a valid network connection (you can easily setup a WiFi or Ethernet connection via the bundled NetworkManager applet, just click on the network icon in the status bar), then issue:

pi64 ~ # emaint sync --repo sakaki-tools pi64 ~ # emaint sync --repo genpi64

Note

If you have time, it is better to do a full software update of your RPi3/4 before proceeding (the process requires about 2 hours). To do this, instead of the above two commands, ensure your RPi has network connectivity, then issue: pi64 ~ # genup All done - your system is now up-to-date! , before proceeding. If you have time, it is better to do asoftware update of your RPi3/4 before proceeding (the process requires about 2 hours). To do this,of the above two commands, ensure your RPi has network connectivity, then issue:and wait for this to finish with the message, before proceeding.

Next, we need to install the sys-apps/flashrom software, which will allow us to read and write the flash chip over the SPI interface. Issue:

pi64 ~ # emerge --ask --verbose sys-apps/flashrom ... additional output suppressed ... Would you like to merge these packages? [Yes/No] <press y, then press Enter> ... additional output suppressed ...

Because it will fetch and then check the binhost packages metadata file, this command may take 3-4 minutes before prompting you whether to proceed, so please be patient. The actual package itself is available as a binary and will install quickly (with no local compilation required), once confirmed.

Note

If you are not using the atapromise USE flag needs to be disabled on arm64 (on the image, this is done via a If you areusing the specified 64-bit Gentoo image on your RPi3/4, please note that theUSE flag needs to be disabled on(on the image, this is done via a custom profile ).

Then, we need to emerge the coreboot-utils package, which provides ifdtool (a utility to parse and modify the structure of Intel firmware flash dumps). The package has an ebuild in the sakaki-tools repository (aka 'overlay') used on the image, so issue:

pi64 ~ # emerge --ask --verbose sys-apps/coreboot-utils ... additional output suppressed ... Would you like to merge these packages? [Yes/No] <press y, then press Enter> ... additional output suppressed ...

Note

If you are not using the If you areusing the specified 64-bit Gentoo image , follow the instructions given here to clone and build the software directly.

Note

For avoidance of doubt, we are not going to be overwriting your BIOS with

And, of course, if you are running coreboot, that's fine too ^-^ For avoidance of doubt, we aregoing to be overwriting your BIOS with coreboot , we just need access to some of its bundled tools. As mentioned earlier , it is fine to use a target PC with an OEM BIOS (such as AMI, Dell etc.).And, of course, if yourunning coreboot, that's fine too ^-^

The next step is to install Nicola Corna's me_cleaner software itself. This also has an ebuild in the sakaki-tools repo, so issue:

pi64 ~ # emerge --ask --verbose sys-apps/me_cleaner ... additional output suppressed ... Would you like to merge these packages? [Yes/No] <press y, then press Enter> ... additional output suppressed ...

Note

If you are not using the If you areusing the specified 64-bit Gentoo image , follow the instructions given here to clone the software directly.

me_cleaner is a reasonably straightforward Python script. Nevertheless, it is good hygiene to review scripts prior to running them (particularly when they impact such security-critical areas as the IME and BIOS), so do so now. Issue:

pi64 ~ # less /usr/lib/python-exec/python3.6/me_cleaner

Use Page Down and Page Up to navigate within the file, and press q to quit, when done.

Lastly, we'll pull in the pigpio library (and accompanying pigs utility and pigpiod server), which will be used to set the GPIO pins on the header not directly controlled by flashrom). This has an ebuild in the genpi64 repo used on the image, so issue:

pi64 ~ # emerge --ask --verbose dev-libs/pigpio ... additional output suppressed ... Would you like to merge these packages? [Yes/No] <press y, then press Enter> ... additional output suppressed ...

Note

If you are not using the pigpio here. If you areusing the specified 64-bit Gentoo image , you can find links to the underlying source for

Note

This tutorial originally used the wiringpi package for GPIO access, but as this has since been deprecated by its author,[17] I have switched to using pigpio instead. This tutorial originally used thepackage for GPIO access, but as this has since been deprecated by its author,I have switched to usinginstead.

Once installed, start the pigpiod daemon, and ensure that this is automatically started each boot; issue:

pi64 ~ # rc-service pigpiod start pi64 ~ # rc-update add pigpiod default

Hardware Configuration

With the necessary software prepared, we can proceed to attach the appropriate IC clip to the RPi's GPIO (general purpose input-output) header.

Cleanly shutdown your RPi3/4:

pi64 ~ # poweroff

Physically remove the RPi3/4's power connector once the shutdown sequence has completed.

With your RPi powered off, locate its 40-pin GPIO header, and connect one end of each of the 8 female-female cables to the appropriate RPi GPIO pin as shown in (the inner, light green section of) the diagram below:

Tip

This header mapping will also work for the Raspberry Pi 1 model B+ or later.

Pin mapping from RPi3/4 GPIO Header to Typical 8-Pin Flash Chip

Here is a photo showing these connections in place on an actual RPi3 (in an official 7" touchscreen enclosure; this is of course not necessary in order to use the board). Disregard the wires on the left-hand side, they are for the touchscreen. With the RPi oriented as it is in this picture, pin 1 is at the extreme left position on the nearer row, and pin 40 at the extreme right position on the farther row. The colours of the jumper wires used match those in the above pin mapping and flash chip pinout.

An RPi3 with GPIO/SPI Connected for Flash Programming to a Pomona 5250 IC Clip (Click to Zoom)

Warning

Be very careful not to connect pins 2 or 4 on the RPi's GPIO header to any pin of the IC clip - these are 5v (rather then 3.3v) and are likely to destroy your flash chip should you accidentally use them.

The other end of the 8 wires you should connect to an appropriate IC test clip, per the outer (lilac) section of the above pin mapping diagram. The photo above shows a 5250 clip attached (as is appropriate for the SOIC-8 flash chip in the Panasonic CF-AX3); obviously, adapt as required. The important thing is to look at your flash IC's pin names / functions (as given by its datasheet), and ensure that these are connected to the appropriate header wire from the RPi3/4. For example, with the Winbond W25Q64FV chip in a SOIC-8 package, as here, we have:

IC Pin IC Name Wire Colour RPi3/4 Pin RPi3/4 Name Function 1 /CS White 24 SPI_CE0_N Chip select; drive low to enable device 2 DO Grey 21 SPI_MISO Standard SPI data output (from chip) 3 /WP Blue 16 GPIO23 / GPIO_GEN4 Write protect; drive high to enable status registers to be written 4 GND Black 25 Ground Ground 5 DI Orange 19 SPI_MOSI Standard SPI data input (to chip) 6 CLK Yellow 23 SPI_CLK SPI clock 7 /HOLD Green 18 GPIO24 / GPI_GEN5 Hold; drive low to pause device while actively selected 8 VCC Red 17 3.3v Power supply (NB do not use 5v)

Note

The '/' in front of some IC signal names implies that their logic is inverted. So, for example, with /WP ("write protect"), we must drive the line low to write-protect the status registers on the flash chip, and high to write-enable them.

With the test clip connected, hardware setup of your RPi as a in-circuit flash programmer is complete.

Reading and Verifying the Original Contents of your BIOS Flash Chip

Power the RPi back up, wait for Gentoo to boot, and then and open a terminal window (or, at your option, log in over ssh). As before, become root:

demouser@pi64 ~ $ sudo su --login root

Then, as root, ensure that /WP and /HOLD are both pulled high. Issue:

pi64 ~ # pigs pud 23 u pi64 ~ # pigs pud 24 u

These commands (using the pigs client from pigpio) activates the RPi3/4's internal pull-up resistors on GPIO23 (RPi pin 16 → /WP) and GPIO24 (RPi pin 18 → /HOLD) respectively.

Note

These two lines are not part of the SPI interface managed by flashrom , so we must explicitly set them to appropriate values, as here.

Note

If (and only if) these pigs commands fail with an error message (rather than returning silently), ensure you have an up-to-date version of pigpio installed, and have the pigpiod daemon running, by issing: pi64 ~ # emaint sync --repo genpi64 pi64 ~ # emerge --verbose dev-libs/pigpio pi64 ~ # rc-service pigpiod start pi64 ~ # rc-update add pigpiod default pigs commands once done.

For avoidance of doubt, most users should not have to issue the commands in this note. If (and only if) thesecommandswith an error message (rather than returning silently), ensure you have an up-to-date version ofinstalled, and have thedaemon running, by issing:Then retry the abovecommands once done.For avoidance of doubt, most users shouldhave to issue the commands in this note.

Next, observing proper proper ESD precautions (and after double-checking that you have all external power supplies and batteries removed), attach the IC clip to your target PC's BIOS flash chip.

For example, the photo below shows the same RPi3 as shown earlier attached to the BIOS chip of the CF-AX3 laptop, using a Pomona 5250 test clip:

Using an RPi3 for In-Circuit BIOS Chip Reflashing of a CF-AX3 (Click to Zoom)

Note

The wire colours used are the same as in the rest of this guide (but other than consistency, there is nothing 'magic' about them ^-^).

Pin 1 is on the bottom left of the flash chip in the above (and corresponds to the white wire on the Pomona 5250 IC clip).

With the clip attached, request that flashrom 'probe' to see if it can identify your BIOS flash chip:

pi64 ~ # flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 flashrom v0.9.9-r1955 on Linux 4.10.17-v8-9411792647f6+ (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on linux_spi. No operations were specified.

Obviously the output will reflect your particular version of flashrom, kernel and flash chip, but if you see something like the above, you are good to proceed.

Note

You can also specify the actual device using the -c <chipname> parameter to flashrom if you like; for example, on the Panasonic CF-AX3 you would would use: pi64 ~ # flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -c W25Q64.V flashrom complains when you probe that " Multiple flash chip definitions match... [p]lease specify which chip definition to use ", then you must use this option (with all flashrom commands in this guide) to disambiguate (obviously, use the appropriate chipname for your setup, if you do). using theparameter toif you like; for example, on the Panasonic CF-AX3 you would would use:With most devices this is unnecessary; however, ifcomplains when you probe that "", then youuse this option (with allcommands in this guide) to disambiguate (obviously, use the appropriatefor your setup, if you do).

However, if instead you got an output containing No EEPROM/flash device found , then you have a problem. Double-check the wiring to your RPi3/4 and the IC clip, and make sure your RPi's power supply is sufficient. If that all looks good, re-seat the IC clip on your flash chip, and try again. The clips are tricky to get seated properly, so it is not unusual for a few tries to be required before flashrom can successfully connect.

Warning

If flashrom reports that it has found a brand or make of chip that doesn't match what you expected, stop. Search online and only proceed if you are confident there is no ambiguity.

Tip

You can see all flashrom 's supported devices with: pi64 ~ # flashrom --list-supported flashrom will work correctly with most encountered flash devices though). You can see all's supported devices with:If your device is not shown you may be unable to proceed (work correctly with most encountered flash devices though).

Once you have a successful probe, leaving the clip in place, dump a copy of your existing firmware:

pi64 ~ # flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -r original.rom flashrom v0.9.9-r1955 on Linux 4.10.17-v8-9411792647f6+ (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on linux_spi. Reading flash... done.

Note

Again, obviously the output you get will most likely differ, but it should follow the pattern above. Make sure you see the Reading flash... done. line in your own output, indicating that the operation has been successful.

Make another copy of the original firmware:

pi64 ~ # flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -r original2.rom

And check that both copies are identical (this is a useful check to ensure that neither image has been corrupted):

pi64 ~ # diff original{,2}.rom

This should produce no output, indicating that the dumped images are identical.

Warning

If diff reports that the two images differ, stop. Repeat the read process until you have two identical copies that pass the diff test. Try reducing the spispeed parameter, and check your clip is properly seated. It is essential that you have a 'known good' backup copy of your original firmware before proceeding, so take care with this step and do not skip it!

Next, assuming the diff check passes, run ifdtool on one of the images, to ensure that it has a valid structure:

pi64 ~ # ifdtool -d original.rom

Your output will obviously be system-specific, but should resemble something like that shown here (at least in broad outline).

Warning

If ifdtool -d reports an error, or states that No Flash Descriptor found in this image , stop. Repeat the read process until you have two identical copies that pass the diff test and this ifdtool -d check.

Finally, check that the dumped image has a structure that the me_cleaner tool understands, and can work with. To do so, issue:

pi64 ~ # me_cleaner --check original.rom

As before, your output will be system-specific, but should pass all checks as for example shown here.

Warning

If me_cleaner --check reports an error, or states that you have an Unknown image , stop. Given that the other tests passed, please me_cleaner , and report your findings. Ifreports an error, or states that you have an. Given that the other tests passed, please open an issue with, and report your findings.

Modifying Firmware using me_cleaner , to Disable the IME

With all tests passed, you can now run me_cleaner on your firmware image. Issue:

pi64 ~ # me_cleaner --soft-disable original.rom --output modified.rom Full image detected The ME/TXE region goes from 0x3000 to 0x280000 Found FPT header at 0x3010 Found 21 partition(s) Found FTPR header: FTPR partition spans from 0x4e000 to 0xd4000 ME/TXE firmware version 9.5.3.1520 Removing extra partitions... Removing extra partition entries in FPT... Removing EFFS presence flag... Correcting checksum (0xe3)... Reading FTPR modules list... UPDATE (LZMA , 0x0b1e05 - 0x0b1f0f): removed ROMP (Huffman, fragmented data ): NOT removed, essential BUP (Huffman, fragmented data ): NOT removed, essential KERNEL (Huffman, fragmented data ): removed POLICY (Huffman, fragmented data ): removed FTPM (LZMA , 0x0b1f0f - 0x0bfbe1): removed HOSTCOMM (LZMA , 0x0bfbe1 - 0x0c81af): removed TDT (LZMA , 0x0c81af - 0x0cd4ed): removed FPF (LZMA , 0x0cd4ed - 0x0ceff8): removed The ME minimum size should be 430080 bytes (0x69000 bytes) The ME region can be reduced up to: 00003000:0006bfff me Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME... Checking the FTPR RSA signature... VALID Done! Good luck!

Your output will obviously differ (and in particular, if you are using a more modern PC than the CF-AX3 you may see a larger number of modules listed (and on a server-class machine, many fewer); see the me_cleaner success reports, for examples of the sort of output that may be produced).

Note

We have used the --soft-disable flag here to both purge unneeded ME firmware and set the AltMeDisable/HAP bit (requesting the ME to do a clean self-disable during the bring-up phase) as noted We have used theflag here topurge unneeded ME firmwareset the AltMeDisable/HAP bit (requesting the ME to do a clean self-disable during the bring-up phase) as noted earlier

The resulting image is saved to the file modified.rom; the original firmware files are left untouched.

Writing Back the Modified Firmware

We can now write back ('reflash') the system firmware we have just modified. With the IC clip still in place, issue:

pi64 ~ # flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -w modified.rom flashrom v0.9.9-r1955 on Linux 4.10.17-v8-9411792647f6+ (aarch64) flashrom is free software, get the source code at https://flashrom.org Calibrating delay loop... OK. Found Winbond flash chip "W25Q64.V" (8192 kB, SPI) on linux_spi. Reading old flash chip contents... done. Erasing and writing flash chip... Erase/write done. Verifying flash... VERIFIED.

As before, your output will most likely differ somewhat, depending on the specifics of your setup.

Warning

If flashrom reports an error here, or does not finish with the output Verifying flash... VERIFIED , stop. You almost surely have a corrupted flash. Try the write again, using a slower spispeed parameter, and if that also fails, try re-seating the IC clip. Ensure you have the /WP and /HOLD pullups active as was specified flashrom using the -c parameter, as was discussed Ifreports an error here, or does not finish with the output. You almost surely have a corrupted flash. Try the write again, using a slowerparameter, and if that also fails, try re-seating the IC clip. Ensure you have theandpullups active as was specified earlier . You can also try specifying the exact model name tousing theparameter, as was discussed above

Once the flash has been successfully programmed, disconnect the IC-clip (or, if you are using a socketed chip and have it e.g. mounted on a solderless breadboard, remove the flash chip and place it back carefully in its socket on your PC).

Restarting your PC and Verifying the IME is Disabled

Reassemble your target PC, following instructions given in your vendor's maintenance manual where available (and as always taking care to observe proper proper ESD protective measures). Ensure any batteries or power supplies are reconnected, and then try booting it up (into Gentoo) using your regular procedure.

If you experience serious problems upon restart — for example, the machine will not POST, or you are unable to enter the BIOS setup GUI after boot — then jump here for instructions on how to recover (by reflashing your original firmware again).

However, in the more likely case that your machine appears to start up correctly into Linux (after you enter your LUKS passphrase etc.), you can run the intelmetool to check the status of the ME. This is available as part of the coreboot-utils package on the sakaki-tools ebuild repository (aka 'overlay') which we already set up earlier in the guide, so, to install it, open a terminal (on your target PC), become root, and issue:

koneko ~ # emaint sync --repo sakaki-tools koneko ~ # mkdir -p -v /etc/portage/package.unmask koneko ~ # echo "sys-apps/coreboot-utils::sakaki-tools" >> /etc/portage/package.unmask/coreboot-utils koneko ~ # emerge --ask --verbose sys-apps/coreboot-utils ... additional output suppressed ... Would you like to merge these packages? [Yes/No] <press y, then press Enter> ... additional output suppressed ...

Note

The host name you see when running these commands will obviously reflect the settings on your target PC.

Note

If you have not installed the sakaki-tools ebuild repository (its use was specified If you haveinstalled theebuild repository (its use was specified earlier in the guide), then please follow the instructions given here to clone and build the software directly.

Note

For avoidance of doubt, intelmetool is usable both on systems with an OEM (e.g. AMI, Dell etc.) BIOS and on those running For avoidance of doubt,is usableon systems with an OEM (e.g. AMI, Dell etc.) BIOS and on those running coreboot

Then issue:

koneko ~ # intelmetool --show Bad news, you have a `8 Series LPC Controller` so you have ME hardware on board and you can't control or disable it, continuing... MEI was hidden on PCI, now unlocked MEI found: [8086:9c3a] 8 Series HECI #0 ME Status : 0x1e020191 ME Status 2 : 0x104d0142 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: Current Working State : Initializing ME: Current Operation State : Bring up ME: Current Operation Mode : Debug ME: Error Code : No Error ME: Progress Phase : BUP Phase ME: Power Management Event : Clean Moff->Mx wake ME: Progress Phase State : 0x4d ME: Extend SHA-256: <hash> ME: failed to become ready ME: failed to become ready ME: GET FW VERSION message failed ME: failed to become ready ME: failed to become ready ME: GET FWCAPS message failed Re-hiding MEI device...done

Again, the output on your system will probably differ from this. You can safely ignore the ominous sounding Bad news... message, as that actually only indicates that the very low-level status registers of the ME are visible over PCI. The real indications that the ME is disabled are that you see (depending on your ME version) one or more of the below:

ME: Firmware Init Complete : NO (as in the above);

(as in the above); ME: Error Code : Image Failure ;

; ME: Current Working State : Initializing (as in the above);

(as in the above); ME: Current Operation Mode : (null) ;

; ME: Current Operation State : Bring up (as in the above);

(as in the above); ME: Progress Phase : Uncategorized Failure ;

; ME: Progress Phase : BUP Phase (as in the above);

(as in the above); ME: Progress Phase State : Check to see if straps say ME DISABLED ;

; ME: Progress Phase State : 0x4d (as in the above);

(as in the above); ME: Progress Phase State : Unknown 0x40 ;

; ME: has a broken implementation on your board with this BIOS ;

; ME: GET FW VERSION message failed (as in the above); or

(as in the above); or ME: GET FWCAPS message failed (as in the above).





Note

If intelmetool reports an error similar to Could not map MEI PCI device memory , please see Ifreports an error similar to, please see these notes for a solution.

You can also browse through the me_cleaner success reports, to see the sort of output that may be produced on different platforms.

Next, wait for 30 minutes of wall time to elapse, and ensure that your target PC does not reset itself (thereby proving that the watchdog timer has been properly cleared).

Note

If you don't see ME: Current Working State : Platform Disable Wait in the output from intelmetool , you can confident that the watchdog has been successfully disabled (and can safely skip the 30 minute check).

If all that worked, congratulations! You have disabled the ME on your PC — click here to skip to the next step.

If however you experience a problem booting (and cannot e.g. start Windows either, assuming you are dual-booting), then continue reading immediately below, to restore the original firmware image again.

Recovery in Case of Error

The me_cleaner process just described does not work on all machines. Fortunately, since you saved a copy of your original firmware earlier, and have a functional flash reprogrammer (the RPi3/4) to hand, it is straightforward to roll things back.

Note

However, before rolling back your firmware, is is worth noting that on some systems, the me_cleaner process will cause the BIOS' state to be erased. As such, you may find e.g., that your target PC has fallen back to legacy boot mode, that your custom secure boot keys have been deleted and so on, but that you can still enter the BIOS GUI on boot (by pressing the appropriate hotkey).



If this happens to you, you can recover your Gentoo system straightforwardly (and will probably not require a rollback reflash). To do so, enter the BIOS GUI, make sure UEFI (not legacy) booting is selected, and turn off secure boot, if enabled. Then, temporarily rename the kernel file /EFI/Boot/gentoo.efi on your boot USB key to /EFI/Boot/bootx64.efi (this can be done on any PC, including a Windows box). Insert the boot USB key into your target PC, and restart, entering the BIOS GUI once more. In the BIOS, select the boot USB key as the highest priority boot device, and exit, saving changes (on a few BIOSes, you may also need to specify the full /EFI/Boot/bootx64.efi path here). Your Linux system should now start up, with the familiar LUKS prompt etc. Once back in your Gentoo desktop again, leave the boot USB key inserted, open a terminal window, and run (without arguments, as root) buildkernel , which should reset your EFI boot order list (and put a fresh copy of (/boot/efi)/EFI/Boot/gentoo.efi on your boot USB key. You can now delete the temporary file (/boot/efi)/EFI/Boot/bootx64.efi if you like. Reboot, and you should find that this new kernel starts up correctly.



Having done this, follow the instructions given in the "Installing New Keys into the Keystore" section (ff.) of the "Configuring Secure Boot" chapter (which may be found systemd users, and OpenRC ) to re-install your (existing) secure boot keys, and re-activate and test secure boot.



If the process just described works for you, congratulations, your system should be functioning normally again! Rejoin the tutorial not work, continuing reading However,rolling back your firmware, is is worth noting that on some systems, theprocess will cause the BIOS'to be erased. As such, you may find e.g., that your target PC has fallen back to legacy boot mode, that your custom secure boot keys have been deleted and so on, but that youstill enter the BIOS GUI on boot (by pressing the appropriate hotkey).If this happens to you, you can recover your Gentoo system straightforwardly (and will probablyrequire a rollback reflash). To do so, enter the BIOS GUI, make sure UEFI (not legacy) booting is selected, and turn off secure boot, if enabled. Then, temporarily rename the kernel fileon your boot USB key to(this can be done on any PC, including a Windows box). Insert the boot USB key into your target PC, and restart, entering the BIOS GUI once more. In the BIOS, select the boot USB key as the highest priority boot device, and exit, saving changes (on a few BIOSes, you may also need to specify the fullpath here). Your Linux system should now start up, with the familiar LUKS prompt etc. Once back in your Gentoo desktop again, leave the boot USB key inserted, open a terminal window, and run (without arguments, as root), which should reset your EFI boot order list (and put a fresh copy ofon your boot USB key. You can now delete the temporary fileif you like. Reboot, and you should find that this new kernel starts up correctly.Having done this, follow the instructions given in the "Installing New Keys into the Keystore" section (.) of the "Configuring Secure Boot" chapter (which may be found here forusers, and here for those using) to re-install your (existing) secure boot keys, and re-activate and test secure boot.If the process just described works for you, congratulations, your system should be functioning normally again! Rejoin the tutorial above , and check that the IME has been successfully disabled on your machine. If, however, it didwork, continuing reading immediately below , to roll back your firmware.

To restore the original firmware image, simply follow the previous instructions to power down your PC, expose the system motherboard, and (re)connect the RPi flash programmer's IC clip. Then on the RPi, working as root, issue:

pi64 ~ # pigs pud 23 u pi64 ~ # pigs pud 24 u pi64 ~ # flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=8000 -w original.rom ... additional output suppressed ... Verifying flash... VERIFIED.

to write the original firmware image back again. When done (make sure you see the Verifying flash... VERIFIED output), follow the earlier procedure to disconnect the IC clip, reassemble your target PC, and boot it up.

In this case, unfortunately it appears that the IME cannot be disabled on your system at this time.

Next Steps

If you were successful restarting your system after running me_cleaner (and it passed the intelmetool --show test), please consider posting details of your system here, to assist others.

However, if you experienced a problem during the process, please take the time to post an new issue here.

Finally, to rejoin the main guide, please click here (systemd) or here (OpenRC).