Open Mhowser opened 5 years ago
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
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 .
nearly identical:
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 .
yep, works fine on all them I've tested on
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 .
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).
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.
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.
"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
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.
@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).
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
@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?
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)
@MrChromebox I'm guessing that it should be fine on any Chromebook OS device with up to 8th or 9th Gen Intel Core processors?
@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.
@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).
there are several different "8th gen" mobile platforms:
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
@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).
@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?
@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.
@moriel5
Thanks
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?
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
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.
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
@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?
@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.
@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?
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
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
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.
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
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
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
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
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.
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?
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.
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?
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 interfaceAbout 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
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?
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.
Would this be possible to implement?