Closed persmule closed 7 years ago
citypw
commented
7 years ago Tested "me_cleaner -s *.rom" on P10S-M WS( Skylake): The booting process became very slow after enabled HAP bit. I tried about 10 times to boot but only succeed at once. Maybe some private UEFI messed something with? It works mostly. Thanks!
corna
commented
7 years ago @citypw So it worked well and fast without the HAP bit and now it is slower?
nroach44
commented
7 years ago Interestingly I've also noticed it takes slightly longer (like 3s more) for coreboot/seabios to turn on the backlight, but I'm not certain that was because of this test or the ME relocation/truncation I did. It's not huge so if it did indeed effect it, it may just be coreboot timing out waiting for the ME to respond.
skochinsky
commented
7 years ago I think coreboot needs to skip the rest of ME init if opmode is 2, this may improve boot speed.
raburton
commented
7 years ago FYI, tested new -s option with i7-4790 on MSI B85-G41, bios v2.9. MSInfo produces a very odd output, although I assume ME has been disabled and the PC has been running for 40 minutes so far without a watchdog reset.
grudnevkv
commented
7 years ago @raburton Strange output is a result of running Intel(R) MEInfo Version: 11.0.15.1003 for Intel i7-4790 It's 4-th generation, not Skylake or higher, thus you need MEinfo utility for lower versions of ME MEInfo with version >= v11 is for 6,7 generations of CPU (Skylake, Kabylake)
me_cleaner outputs ME version of your image in output log, thus you need to use MEInfo for version received from me_cleaner
Intel i7-4790 most likely needs MEInfo v10.*
raburton
commented
7 years ago @grudnevkv Thanks for the tip. I did wonder if matched versions was important, but MEInfo v11 worked fine before the modification, so I assumed the tools were backwards compatible! My ME version is 9.0.30.1482. Using MEInfo 9.0.22.1467 I get the normal output again (which shows Alt Disable Mode) plus a load of errors trying to communicate with the ME and all that junk I got from the v11 tool. Anyway, I think this is the first tested ME v9 and it looks like the disable has worked.
citypw
commented
7 years ago @corna yes, it's running much faster w/o HAP enabled. "-s" doesn't remove the code modules disabled the ME only: https://twitter.com/hardenedlinux/status/903158983015358464
nroach44
commented
7 years ago Running -s on an Asus P8Z68M-Pro with the stock ASUS BIOS delays boot slightly, and seemingly broke AHCI for a few boots, but that might have been my connections being funky.
Bad news, you have a `Z68 Express Chipset Family 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:1c3a] 6 Series/C200 Series Chipset Family MEI Controller #1
ME Status : 0x1e020191
ME Status 2 : 0x160a0100
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 : Pseudo-global reset
ME: Progress Phase State : Check to see if straps say ME DISABLED
ME: Extend SHA-256: fcf867b12599c9a59e661ee6c20fa9c22b5b9e0a513bb21791cec49b33570ce5
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...doneI'm afraid I'll have to make the HAP/AltMeDisable a non-default option.
archfan
commented
7 years ago Strange. Am I the only one who has improved boot times w/ HAP?
citypw
commented
7 years ago @corna agreed! HAP enabled might be trouble to some OEM firmwares while coreboot is working good so far.
corna
commented
7 years ago @citypw An option to set or not the HAP/AltMeDisable bit is needed, however I can't decide which should be the default behaviour: the HAP/AltMeDisable bit is a cleaner way (and coreboot can even detect that the ME has been disabled, which could improve the boot time with some tweaks in the raminit code, as suggested by @skochinsky), however some OEM BIOS seems to behave worse. I'll think about it.
nroach44
commented
7 years ago FWIW my P8Z68M-Pro mentioned above has never been me_cleaned before, so the reported behaviour would likely be worse had I done more than the AltDisable bit.
Also my X220 report - the region had been cleaned prior, but every attempt at relocation resulted in the backlight coming on later than usual, and likely resulted in me thinking I'd bricked the machine (see #20 where I maintained that relocation never seemed to work for me towards the end).
My argument would be set it as default, because as you've mentioned, it /should/ be the better way of doing it, and is likely better handled (on average) by vendor BIOS'.
TheEffbee
commented
7 years ago ASUS Z170M-E D3 with BIOS 2203 and a Kaby Lake i5 7600k. Cleaned and HAP bit set. ME version: 11.6.13.1212
CurrentState: Disabled ManufacturingMode: Disabled FlashPartition: Valid OperationalState: Transitioning InitComplete: Initializing BUPLoadState: Success ErrorCode: Disabled ModeOfOperation: Alt Disable Mode SPI Flash Log: Not Present Phase: BringUp ICC: No valid OEM data, ICC programmed with default values ME File System Corrupted: No PhaseStatus: UNKNOWN FPF and ME Config Status: Match
Error 86: Communication error between application and Intel(R) ME module (FWU client)
Error 81: Internal error (Could not determine FW features information)
kakaroto
commented
7 years ago @corna yes, please make the HAP bit an option, because it's simply not working for me here. I've tried it on two Librem 13 v2 machines and one Librem 15 v3 machine, and all 3 are exhibiting the same behavior, after the HAP bit is set, the machine will refuse to boot. When I turn it on, the power LED will light up for a second then it will shut down, then the hdd LED will start blinking very slowly. At first, I thought the machine was in a boot loop but I don't think that's the case anymore, I just think the LED blinks very slowly, I think it just refuses to boot somehow. No matter what I do, press power button, hold it for a minute, any key combination, nothing works, the laptop refuses to boot anymore (and doesn't stop blinking that LED). The only way I found to stop it was to remove the battery. I've tried setting the HAP bit with both the ME cleaned and with the ME intact, I also tried setting it using the official (FIT) tool and setting that "Reserved" bit in it (which did enable the exact same bit in the descriptor). All 3 machines were running coreboot, I didn't try with any other BIOS though.
Note that my machine came with ME version 11.0.0.1180, so I thought I'd try a higher version and tried version 11.0.18.1002 that I found online, and setting the HAP bit did not cause this same problem, it booted fine but with the ME disabled, as expected. I tried with both a neutralized and non neutralized ME, same behavior in both cases (cbmem shows the ME disabled as expected). So I think the HAP bit isn't valid for ME > 11.0 but maybe it's only valid for ME > 11.0.x.y It would be good if we could get people to report their exact ME version so we can find which is the version of the ME which introduced this feature and make sure me_cleaner doesn't enable it for earlier versions since it's a guaranteed brick in that case.
1asdqwe
commented
7 years ago ASUS P8Z77, i5-3570k, ME8.
Intel(R) MEInfo Version: 8.1.10.1286 Copyright(C) 2005 - 2012, Intel Corporation. All rights reserved.
FW Status Register1: 0x1C020181 FW Status Register2: 0x120A0110
CurrentState: Init ManufacturingMode: Disabled FlashPartition: Valid OperationalState: Bring Up InitComplete: Initializing BUPLoadState: Success ErrorCode: No Error ModeOfOperation: Alt Disable Mode ICC: No valid OEM data, ICC not programmed PhaseStatus: CHECK_ME_STRAP_DISABLED
It is necessary to make, that was so: . . . . ModeOfOperation: Alt Disable Mode ICC: Valid OEM data, ICC programmed PhaseStatus: CHECK_ME_STRAP_DISABLED
corna
commented
7 years ago @kakaroto
please make the HAP bit an option
I've decided to revert back to the previous behavior, see the latest commit on the dev branch. Now the HAP bit is an opt-in feature (-s only sets the HAP bit while -S does the full cleaning process and sets the HAP bit).
So I think the HAP bit isn't valid for ME > 11.0 but maybe it's only valid for ME > 11.0.x.y
Thank you, I'll test it on my PC and I'll add a blacklist on the ME versions if you're right.
1asdqwe
commented
7 years ago Dear Nicola Corna!
I have a problem with the dynamic overclocking of the processor. I believe that the ICC should be able to be programmed. How to do it.
ASUS P8Z77, i5-3570k, ME8. Intel(R) MEInfo Version: 8.1.10.1286 Copyright(C) 2005 - 2012, Intel Corporation. All rights reserved. FW Status Register1: 0x1C020181 FW Status Register2: 0x120A0110 CurrentState: Init ManufacturingMode: Disabled FlashPartition: Valid OperationalState: Bring Up InitComplete: Initializing BUPLoadState: Success ErrorCode: No Error ModeOfOperation: Alt Disable Mode ICC: No valid OEM data, ICC not programmed PhaseStatus: CHECK_ME_STRAP_DISABLED It is necessary to make, that was so: . . . . ModeOfOperation: Alt Disable Mode ICC: Valid OEM data, ICC programmed PhaseStatus: CHECK_ME_STRAP_DISABLED Yours faithfully, Nikolay (1asdqwe)
Четверг, 7 сентября 2017, 11:43 +04:00 от Nicola Corna notifications@github.com:
@kakaroto
please make the HAP bit an option I've decided to revert back to the previous behavior, see the latest commit on the dev branch. Now the HAP bit is an opt-in feature (-s only sets the HAP bit while -S does the full cleaning process and sets the HAP bit). So I think the HAP bit isn't valid for ME > 11.0 but maybe it's only valid for ME > 11.0.x.y Thank you, I'll test it on my PC and I'll add a blacklist on the ME versions if you're right. — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .
nroach44
commented
7 years ago I've also for some reason (according to a gnome shell extension, not checked out extensively) lost dynamic clock control, but (I thought) I had it after flashing, so I'm pretty sure it's the OS's fault (at this point). 1asdqwe what OS are you using? I'm on debian testing with a 4.13 kernel.
nroach44
commented
7 years ago So in my case it turns out that /proc/cpuinfo doesn't display "current" MHz (or the scaling is somehow broken) in Linux 4.13.
1asdqwe
commented
7 years ago nroach44 My problem is not with the OS. If there is a firmware with unmodified ME, the dynamic overclocking of the processor works correctly in the range (1.6GHz-3.8GHz). If the firmware is modified with the help of the me_cleaner, then the range will be (1.6GHz-3.6GHz).
eugenezastrogin
commented
7 years ago Hello! I previously used me_cleaner, but with some sleep issues that made it unusable for me. After hearing about killswitch, I decided to give -s option a go, now everything is working great!
Intel Core i7-4770K, Haswell, Gigabyte GA-Z87X-UD3H F10b BIOS. No issues with suspend anymore, intelmetools returns:
sudo intelmetool -s
MEI was hidden on PCI, now unlocked
MEI found: [8086:8c3a] 8 Series/C220 Series Chipset Family MEI Controller #1
ME Status : 0x1e020191
ME Status 2 : 0x164d2106
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 : Pseudo-global reset
ME: Progress Phase State : 0x4d
ME: Extend SHA-256: 393ffb341d635e1b11e5f5d155496bfed996e7435a367e564740b8bb4038796a
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...doneThank you for your work!
corna
commented
7 years ago @kakaroto I've tried ME 11.0.x.y on my board (without any modification and HAP unset) but it bricked it. This board came originally with 11.6.1.1142 and I think it doesn't work at all with earlier versions of ME. Unfortunately I won't be able to find which version is the first one to support the HAP bit.
kakaroto
commented
7 years ago @corna yes, I expect that's normal, 11.0.x is for Skylake, and 11.6.x is for Kabylake if I remember correctly. It wouldn't work as far as I know. I don't know why it went from 11.0 to 11.6 instead of 12.0, but that's how it is. I can try and test various versions on my SKL machines and will let you know what I find.
corna
commented
7 years ago @kakaroto That's what I expected, however the MB has a H110 Sunrise Point PCH, which is a Skylake-era chipset. I don't know why it ships ME 11.6.
platomav
commented
7 years ago 11.0 SPT_SKL 11.5 SPT_SKL, SPT_KBL, KBP_KBL (LP, EOL) 11.6 SPT_SKL, SPT_KBL, KBP_KBL (H & LP) 11.7 SPT_SKL, SPT_KBL, KBP_KBL(R), CNP_CFL 11.10 BSF_SKL-X/KBL-X 11.20 LBG_SKL-SP
May it be useful to you. Disabling Intel ME 11 via undocumented mode