FR: Disable Intel's Management Engine

[Mhowser]

Would this be possible to implement?

[MrChromebox]

the firmware I build is designed to be flashed on the system itself, and so assumes that the ME firmware region cannot be written to. If you want to disable the ME, you'll need an external programmer and to simply use ME Cleaner to disable the ME, then flash the "cleaned" image back to the device

[Mhowser]

Is that a similar procedure to unbricking a device?

https://wiki.mrchromebox.tech/Unbricking

On Wed, May 1, 2019, 9:00 PM MrChromebox notifications@github.com wrote:

the firmware I build is designed to be flashed on the system itself, and so assumes that the ME firmware region cannot be written to. If you want to disable the ME, you'll need an external programmer and to simply use ME Cleaner to disable the ME, then flash the "cleaned" image back to the device

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MrChromebox/firmware/issues/139#issuecomment-488546392, or mute the thread https://github.com/notifications/unsubscribe-auth/AFYTD5AP3IORGKO67PQ3OZLPTJRMRANCNFSM4HJ3BZVQ .

[MrChromebox]

nearly identical:

• read current firmware
• run ME cleaner on it
• flash back to device

[Mhowser]

That's great! Have you tried this on any of your Chromebooks?

On Wed, May 1, 2019, 9:32 PM MrChromebox notifications@github.com wrote:

nearly identical:

• read current firmware
• run ME cleaner on it
• flash back to device

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MrChromebox/firmware/issues/139#issuecomment-488550381, or mute the thread https://github.com/notifications/unsubscribe-auth/AFYTD5DJXQROWAAMMNA62MLPTJVGTANCNFSM4HJ3BZVQ .

[MrChromebox]

yep, works fine on all them I've tested on

[Mhowser]

Wonderful! Thanks for the info!

I'll try this out once I can find a good programming clip.

On Wed, May 1, 2019, 9:39 PM MrChromebox notifications@github.com wrote:

yep, works fine on all them I've tested on

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/MrChromebox/firmware/issues/139#issuecomment-488551211, or mute the thread https://github.com/notifications/unsubscribe-auth/AFYTD5AEZ7PCZABSUM4YC33PTJWA3ANCNFSM4HJ3BZVQ .

[moriel5]

I have a question, after using ME Cleaner, and having flashed via external flashing, I understand that I will still need to use ME Cleaner on subsequent firmware updates, however will I be able to flash them internally now, or will I need to flash via external means each time?

My SOIC-8 clips have gotten detached from the wiring, and I am having a hard time pulling the wires out of the sleeves so I could solder them, so I am hoping that I wont need them for my sister's laptop now (I had already flashed the cleaned image with them before this had happened).

[MrChromebox]

there is no need to use ME Cleaner on subsequent updates, simply keep the flash descriptor locked and the IFD/ME will remain unable to be written via internal flashing, same as they are now. Then internal updates will only apply to the BIOS region.

[moriel5]

Thanks, though as a rookie (I am learning, though), I fail to understand what do you mean by "keeping the flash descriptor locked".

Essentially, I had removed the write-protect screw from the laptop the day it arrived in our home, though from what I had read over on the Win-Raid forum, this should be part of the firmware itself.

Does this mean that as long as I do not modify the firmware, I can flash it without worrying about the TXT firmware being flashed?

Update: In the end I modified the firmware.sh script to point directly at the cleaned firmware, since I won't be home for the next few weeks. However, I'd still like to understand what you had meant.

[MrChromebox]

"keeping the flash descriptor locked"

the flash descriptor (IFD) is a 4kb section at the start of the flash chip, it defines the layout of the flash chip and sets permissions for the various regions.

Especially, I had removed the write-protect screw from the laptop the day it arrived in our home, though from what I had read over on the Win-Raid forum, this should be part of the firmware itself.

completely separate from the flash descriptor

Does this mean that as long as I do not modify the firmware, I can flash it without worrying about the TXT firmware being flashed?

coreboot has a config option to either unlock the IFD or leave it locked. As long as it is locked when you flash externally, then subsequent internal flashes won't be able to modify the IFD or ME regions

[moriel5]

Then I believe that I had left it locked, as other than using ME Cleaner, and specifying the default FlashROM arguments (with my CH341a), I did not do anything else.

[artemislena]

@MrChromebox Wouldn't it be possible to somehow set the HAP bit from the UEFI settings / shell? Just asking because, while certainly doable, it's not exactly trivial to use an SPI programmer on internal mainboard ROM and so on - and some other devices (some Linux laptops) also allow disabling the ME from the internal UEFI, which is indeed installed on the system. Another idea would be to ship two versions, one with and one without ME, or just have it always disabled (I don't think anyone here would like to use the ME anyway).

[MrChromebox]

Wouldn't it be possible to somehow set the HAP bit from the UEFI settings / shell?

no. The HAP bit is contained in the flash descriptor (IFD) region of the firmware, which is RO on a live/booted system. The only way to change any bits in the IFD is via external programmer.

some other devices (some Linux laptops) also allow disabling the ME from the internal UEFI, which is indeed installed on the system

that's using a different technique. I could likely disable the ME on SKL/KBL devices this way, but it wouldn't be user configurable.

Another idea would be to ship two versions, one with and one without ME, or just have it always disabled (I don't think anyone here would like to use the ME anyway).

there's not much point in me doing so, since it requires flashing with an external programmer on the fast majority of devices I support. Plus, if I shipped ME-disabled images, then the IFD wouldn't match the stock firmware and it would fail validation after flashing (even if I don't write that area, it still gets checked). And there's no way I'm going to double the number of images I build/support. 60+ is unbearable as it is

[ghost]

@MrChromebox

yep, works fine on all them I've tested on

nearly identical:

read current firmware
run ME cleaner on it
flash back to device

Could write a could guide/wiki on this for Flashing ME Cleaner on Chromebooks?

[MrChromebox]

ME cleaner only works for a very small number of older Chromebooks. The process for using ME cleaner is well documented on the ME cleaner github, there's nothing I can add to it (other than I don't recommend it)

[moriel5]

@MrChromebox I'm guessing that it should be fine on any Chromebook OS device with up to 8th or 9th Gen Intel Core processors?

[MrChromebox]

@moriel5 6th/7th-gen ones require whitelisting a module or you'll lose WiFi (and maybe more). 8th-gen and up aren't supported.

But you really need to ask yourself why you think using ME cleaner is necessary, above and beyond the disablement already done in the firmware/by coreboot.

[moriel5]

@MrChromebox Yeah, that sounds about right, after reading back in the day about Puri.sm's attempt at cleaning the ME with SkyLake.

9th Gen alright (though odd, for the upcoming reason), however I would expect 8th Gen (at least Kaby Lake-R) to be supported, as there is barely anything that has changed since 7th Gen (at least, that is how it looks to me).

Regarding necessity of clearing the ME, that is a good question, and something I am pondering in regards to 3mdeb's Dasharo implementation with the Dell Optiplex 7010/9010.

I think that if the only reason is to disable the malicious code, ultimately it doesn't matter, however removing it entirely (in a lab environment) could assist with understanding what would be required for potential replacements (such as a thought I had about a theoretical fork of MultiZone, should it be feasible to do such a thing and adapt it to x86).

[MrChromebox]

there are several different "8th gen" mobile platforms:

• Kabylake-R
• Coffeelake
• Whiskeylake
• Cannonlake

Only KBL-R uses the same ME 11.x firmware as KBL. The others use 12.x and have a completely different firmware filesystem, which ME cleaner cannot parse/strip etc

[moriel5]

@MrChromebox Ah, okay. That certainly makes sense.

Especially as they cannot be updated as easily as the previous versions as well (this is what I understand from what I saw regarding ME 12+ on Win-Raid).

[ghost]

@MrChromebox

there are several different "8th gen" mobile platforms:

Kabylake-R
Coffeelake
Whiskeylake
Cannonlake

Only KBL-R uses the same ME 11.x firmware as KBL. The others use 12.x and have a completely different firmware filesystem, which ME cleaner cannot parse/strip etc

Thanks for info like always :) ....Also how do find out what generation you Intel CPU is?

[moriel5]

@S0yf00d-exe It's actually relatively easy (even though Intel's naming convention is not the most straightforward).

Just check your processor's full model number (before 11th Gen it was i(3/5/7)-XxxxN (X is generation, x is the model, could be anything, like 350, N is TDP designation, like M or Y or U) if it is from one of the Core series (if it's a Pentium or Celeron or Atom it's slightly different, but similar) and check on Intel's ARK website (you may need to use an external search engine if the processor is old enough, however these generations are still new enough to be easily found there), where on the product page it will tell you from which family it is from.

[ghost]

@moriel5

Thanks

[DraconicNEO]

the firmware I build is designed to be flashed on the system itself, and so assumes that the ME firmware region cannot be written to. If you want to disable the ME, you'll need an external programmer and to simply use ME Cleaner to disable the ME, then flash the "cleaned" image back to the device

I know this is a bit late but wasn't there a way for coreboot to disable ME temporarily using the me_state option, or does that require something different in hardware that won't work in chromebooks/chromeboxes?

[MrChromebox]

I know this is a bit late but wasn't there a way for coreboot to disable ME temporarily using the me_state option, or does that require something different in hardware that won't work in chromebooks/chromeboxes?

depending on the ME version, coreboot can send a HECI command to the ME asking it to soft-disable, yes. It's disabled by default on most newer boards, IIRC

[DraconicNEO]

I know this is a bit late but wasn't there a way for coreboot to disable ME temporarily using the me_state option, or does that require something different in hardware that won't work in chromebooks/chromeboxes?

depending on the ME version, coreboot can send a HECI command to the ME asking it to soft-disable, yes. It's disabled by default on most newer boards, IIRC

Oh I see, How new do the newer ones have to be exactly, Mine is a CN60 and it doesn't appear to be disabled.

[MrChromebox]

the CN60 is nearly a decade old now. The build default for it is to have the ME enabled, for users who wanted to run MacOS on it. It can easily be rebuilt with the ME disabled

[ghost]

@MrChromebox

coreboot has a config option to either unlock the IFD or leave it locked. As long as it is locked when you flash externally, then subsequent internal flashes won't be able to modify the IFD or ME regions

Do I need set this in the the bios, I can't find any documentation about how to change the Bios settings like date and time etc?

Can I disable Bluetooth in coreboot bios settings or is that something I need to do like me_cleaner? Also reading your guide i got this ch341a. Do you need Dupont Wires for the me_cleaner on chromebooks or any in general to do this?

• P.S. Thanks for everything you do for the community.

[MrChromebox]

@No802-11 your questions seem unrelated to disabling the ME / using me_cleaner. There are no user-configurable options in coreboot with the way the firmware is built, everything is a build-time option. For the record, I do not recommend disabling the ME or using me_cleaner on any ChromeOS devices -- there's simply no need for it.

[ghost]

@MrChromebox Sorry for the confusion as I was referring to was about having to not flash me_cleaner each time after a new update via the MrChromboxScript.

There are no user-configurable options in coreboot with the way the firmware is built, everything is a build-time option.

Well I was kinda pointing to the UEFI Shell options (couldn't find them online).

After unplugging my battery from board (before unplugging the webcam ribon cable as have no use for it) I had to reset the time & date in the bios with set time 21:08 and set date 5/1/2023 since one of the systems I'm testing doesn't have ntp for time.

Also maybe I thinking of Nvramtool in regards to disabling Bluetooth.

(./nvramtool -C coreboot.rom -w bluetooth=Disable).

I do not recommend disabling the ME or using me_cleaner on any ChromeOS devices -- there's simply no need for it.

Yeah I get that... I just wanted to learn more about/practicing modifying firmware and thought it would be easy with my Chromebooks that have your firmware (coreboot) then adding me_cleaner. As a first time trying before learning and trying to build a coreboot for other machines with me_cleaner if that makes sense. :)

Is this ch341a good enough or do you think one should get another clip aswell?

[MrChromebox]

Sorry for the confusion as I was referring to was about having to not flash me_cleaner each time after a new update via the MrChromboxScript.

you wouldn't have to. MrChromebox updates via script only flash the BIOS region as specified by the IFD

Well I was kinda pointing to the UEFI Shell options (couldn't find them online).

"help" ? IDK

Also maybe I thinking of Nvramtool in regards to disabling Bluetooth.

nvramtool modifies values in CMOS for boards which are built using CONFIG_OPTION_TABLE. No Chromebooks/boxes select this option. And the options table needs to be constructed per board.

Is this ch341a good enough or do you think one should get another clip aswell?

I'd get a Pomona 5250 clip and wires

[mlario]

I know this is a bit late but wasn't there a way for coreboot to disable ME temporarily using the me_state option, or does that require something different in hardware that won't work in chromebooks/chromeboxes?

depending on the ME version, coreboot can send a HECI command to the ME asking it to soft-disable, yes. It's disabled by default on most newer boards, IIRC

Hi,

Could you please disable intel me on HP G3 chromebox (NOIBAT) using HECI method? This is modern platform, CPU is 10th gen

Or at least give an option in bios settings?

Or just give info how to do it myself in coreboot setup?

That would be so helpful

Since I already spent a tone of time desoldering WSON bios chip - that cannot be programmed using regular clip and exchanged it with SOIC chip (existence of probes working with WSON chip I discovered post-factum....).

Then to discover that me-cleaner is currently experimental in identifying and setting HAP bit on platform with me 12.x and up:

https://github.com/corna/me_cleaner/pull/384#issuecomment-1734548774

To only discover that it did not work and board has no video output.

Switching back to your original coreboot image works fine. But then inactivating me with HAP bit is no go, at least currently from what I see

Many thanks

[MrChromebox]

Switching back to your original coreboot image works fine. But then inactivating me with HAP bit is no go, at least currently from what I see

not sure why it would be a no-go -- or even what you mean by that. HAP on Cometlake boards is not a problem.

[mlario]

Switching back to your original coreboot image works fine. But then inactivating me with HAP bit is no go, at least currently from what I see

not sure why it would be a no-go -- or even what you mean by that. HAP on Cometlake boards is not a problem.

Well, NOIBAT board does not boot with HAP bit set. There is fan spin but no video output even after 24 hours of waiting

So that is why it is no go

Identification of HAP bit was also trial and error, but confirmed with Intel FIT tool to be 0x70: https://github.com/corna/me_cleaner/pull/384#issuecomment-1732700377

I attached bios dumps after unsuccessful attempt to boot the board and original bios dump w/o HAP bit set - in case you could have idea what is going wrong there

Could you please provide any info how to set HECI for NIOBAT?

Or could you modify your coreboot build to set HECI for NOIBAT by default?

Thanks bios_dumps.zip

[MrChromebox]

honestly I think the hysteria surrounding the ME without AMT is completely overblown and irrational, and disabling the ME has all sorts of side effects such as increased power consumption, broken sleep, loss of DRM media playback, etc.

Here's a build with HECI disabled by coreboot at the end of boot. The ME/HECI PCI device will not be visible to the OS

coreboot_edk-noibat-no_heci_mrchromebox-4.21.0-1.zip

[mlario]

honestly I think the hysteria surrounding the ME without AMT is completely overblown and irrational, and disabling the ME has all sorts of side effects such as increased power consumption, broken sleep, loss of DRM media playback, etc.

Here's a build with HECI disabled by coreboot at the end of boot. The ME/HECI PCI device will not be visible to the OS

coreboot_edk-noibat-no_heci_mrchromebox-4.21.0-1.zip

Thanks a lot.

This worked like a charm, no intel me PCI device present

Out of curiosity, is HECI controlled here by CONFIG_HAVE_ME_BIN=y : https://github.com/MrChromebox/coreboot/blob/MrChromebox-4.20/configs/cml/config.noibat.uefi

About mass hysteria with intel me, you might be right. Maybe indeed amt is required for functionality

I've even heard disabling/blacklisting mei_me and similar kernel modules is sufficient

But there are others saying HECI is not sufficient since it is just in some kind of interface that intel me might listen to or not:

https://github.com/corna/me_cleaner/pull/384

while HAP is supposed to be better way, it is still one bit and who knows if me is really listening to that either

I'm sure in one thing, as long as source code is not available or reverse engineered nobody knows how exactly intel me works and how to certainly deactivate it

And lack of source code causes irrational suspicions

since me is involved in vulnerabilities, and there are rumors US government and army keep it deactivated I think it is wise to limit intel me activity somehow

It is alarming that old versions could be removed completely, newer only partially, and most recent ones cannot be removed but only asked to be deactivated

It is alarming that intel me functionality, despite all the controversy among consumers, is further developed and more tightly integrated into consumer cpus

it is required for system startup, thunderbolt on some boards, energy states of cpu, can talk to intel wifi card through linux kernel modules (linux kernel as open source community project should be free of that functionality, right?, at least by default, right?), and is even required for touch sensor functionality on modern tablets.

System76, dasharo, starlabs and novacustoms deactivate it

Here is how system76 does it so user can decide if to use it or not:

https://github.com/system76/coreboot/pull/76

and last thing, intel me is what everybody knows and talks about. hardware is closed too - so nobody knows what other functionality is present on the silicon

[MrChromebox]

Out of curiosity, is HECI controlled here by CONFIG_HAVE_ME_BIN=y : https://github.com/MrChromebox/coreboot/blob/MrChromebox-4.20/configs/cml/config.noibat.uefi

no, that controls whether or not the ME firmware binary is included in the build. DISABLE_HECI1_AT_PRE_BOOT is the config which disables the HECI interface

About mass hysteria with intel me, you might be right. Maybe indeed amt is required for functionality

AMT is not required, it's the remote-access functionality of the CORPORATE (vs CONSUMER) ME firmware.

I've even heard disabling/blacklisting mei_me and similar kernel modules is sufficient

that does nothing to disable the HECI interface

while HAP is supposed to be better way, it is still one bit and who knows if me is really listening to that either

The HAP bit is simply asking the ME to disable any external interfaces. You have to trust that it actually does that though.

It is alarming that old versions could be removed completely, newer only partially, and most recent ones cannot be removed but only asked to be deactivated

why is this alarming? New versions are more involved in platform init than older ones.

It is alarming that intel me functionality, despite all the controversy among consumers, is further developed and more tightly integrated into consumer cpus

there is little to no controversy among consumers, the vast majority of people don't care, and those that do are not a large enough block to have any impact on Intel's design decisions.

System76, dasharo, starlabs and novacustoms deactivate it

I know, I've been working in this area before any of those companies offered the feature. It's security theater IMO.

[DraconicNEO]

honestly I think the hysteria surrounding the ME without AMT is completely overblown and irrational, and disabling the ME has all sorts of side effects such as increased power consumption, broken sleep, loss of DRM media playback, etc.

I very much agree, without the AMT and Network component it seems irrational to fear and try to disable IntelME and as pointed out it causes more harm than it solves. Without the AMT it doesn't have any Network access and the majority of systems don't have AMT enabled or even present. People make the "it's closed source so you can't know" argument which is false because you can, IntelME reports this information and even if it didn't or lied, closed source systems can and are audited, picked apart, and explored. Anyone who still pushes that argument about ME is fearmongering for attention in my opinion, which is probably why none of them ever want to talk about (even recoil at the mention of) 34C3 IntelME Myths and Reality because that one annihilates the BS conspiracy filled arguments they push out.

The HAP bit is simply asking the ME to disable any external interfaces. You have to trust that it actually does that though.

Well it can be tested for by monitoring its activity at the hardware level but considering it's an approved solution by the ME-cleaner tools it's reasonable to assume that such testing already took place (for most people it's not necessary to do it themselves), and anyway without AMT (and its associated Network stack) present what's it really doing that's of concern anyway?

[MrChromebox]

considering it's an approved solution by the ME-cleaner tools it's reasonable to assume that such testing already took place

I don't think that's a reasonable assumption at all, given that the original developer of me_cleaner no longer works on the project, it doesn't officially support anything above ME 11.x, and following the solutions in an open PR for the OP's device here resulted in a bricked device.

anyway without AMT (and its associated Network stack) present what's it really doing that's of concern anyway?

well the concern is that it's a potentially exploitable interface which has access to everything, but that's just FUD at this point.

[mlario]

honestly I think the hysteria surrounding the ME without AMT is completely overblown and irrational, and disabling the ME has all sorts of side effects such as increased power consumption, broken sleep, loss of DRM media playback, etc.

I very much agree, without the AMT and Network component it seems irrational to fear and try to disable IntelME and as pointed out it causes more harm than it solves. Without the AMT it doesn't have any Network access and the majority of systems don't have AMT enabled or even present. People make the "it's closed source so you can't know" argument which is false because you can, IntelME reports this information and even if it didn't or lied, closed source systems can and are audited, picked apart, and explored. Anyone who still pushes that argument about ME is fearmongering for attention in my opinion, which is probably why none of them ever want to talk about (even recoil at the mention of) 34C3 IntelME Myths and Reality because that one annihilates the BS conspiracy filled arguments they push out.

thanks for this info, will check the video. curios to see hard facts about whole intel me story

would be curious to see any updates on research during last 6 years on this topic too

The HAP bit is simply asking the ME to disable any external interfaces. You have to trust that it actually does that though.

Well it can be tested for by monitoring its activity at the hardware level but considering it's an approved solution by the ME-cleaner tools it's reasonable to assume that such testing already took place (for most people it's not necessary to do it themselves), and anyway without AMT (and its associated Network stack) present what's it really doing that's of concern anyway?

[mlario]

Out of curiosity, is HECI controlled here by CONFIG_HAVE_ME_BIN=y : https://github.com/MrChromebox/coreboot/blob/MrChromebox-4.20/configs/cml/config.noibat.uefi

no, that controls whether or not the ME firmware binary is included in the build. DISABLE_HECI1_AT_PRE_BOOT is the config which disables the HECI interface

About mass hysteria with intel me, you might be right. Maybe indeed amt is required for functionality

AMT is not required, it's the remote-access functionality of the CORPORATE (vs CONSUMER) ME firmware.

I've even heard disabling/blacklisting mei_me and similar kernel modules is sufficient

that does nothing to disable the HECI interface

while HAP is supposed to be better way, it is still one bit and who knows if me is really listening to that either

The HAP bit is simply asking the ME to disable any external interfaces. You have to trust that it actually does that though.

It is alarming that old versions could be removed completely, newer only partially, and most recent ones cannot be removed but only asked to be deactivated

why is this alarming? New versions are more involved in platform init than older ones.

It is alarming that intel me functionality, despite all the controversy among consumers, is further developed and more tightly integrated into consumer cpus

there is little to no controversy among consumers, the vast majority of people don't care, and those that do are not a large enough block to have any impact on Intel's design decisions.

System76, dasharo, starlabs and novacustoms deactivate it

I know, I've been working in this area before any of those companies offered the feature. It's security theater IMO.

yeah, topic is controversial

anyway thanks for the build, and info about HECI. maybe will try to compile myself the other day just for fun

[Martin-K24]

So this is my model information according to the GalliumOS wiki

Model	Codename	Year	Processor
Acer Chromebook 14 (CB3-431)	EDGAR	2016	Intel Braswell

So is it completely not possible to run me_cleaner or set the HAP bit and then re-flash internally?

After flashing with firmware script I booted with iomem=relaxed and ran the intemetool.\ However I was unable to get the status of the Intel ME as it couldn't detect the processor.

I think a part on disabling Intel ME should be added to the Chultrabook Docs: https://docs.chrultrabook.com/docs/firmware/

Also would it be possible to add support for ARM based chromebooks by detecting the architecture and building libreboot images with u-boot payload?

[MrChromebox]

So is it completely not possible to run me_cleaner or set the HAP bit and then re-flash internally?

On a device with an Intel ME, it is not possible on any device which is locked (which is how all Chromebooks ship), unless one first flashes the device externally to enable the ME to be read/written via internal flashing.

After flashing with firmware script I booted with iomem=relaxed and ran the intemetool. However I was unable to get the status of the Intel ME as it couldn't detect the processor.

Did you consider the possibility that your device doesn't have/use an Intel ME? Braswell uses TXT, not ME.

I think a part on disabling Intel ME should be added to the Chultrabook Docs: https://docs.chrultrabook.com/docs/firmware/

why? what does it have to do with the project? And if you want something added to the chrultrabook docs, why are you not opening an issue there?

Also would it be possible to add support for ARM based chromebooks by detecting the architecture and building libreboot images with u-boot payload?

no, this project is x86_64 only currently. One can follow LB's instructions to flash LB if one is so inclined.