corna
Effect on Lenovo X1 Carbon Gen2
Intel Core i7-4600U
Haswell
Lenovo X1 Carbon Gen2
OEM BIOS
0bf14b8
The keyboard lights up briefly then the computer shuts down (nothing is displayed on the screen).
I followed this tutorial : http://hardenedlinux.org/firmware/2016/11/17/neutralize_ME_firmware_on_sandybridge_and_ivybridge.html
It works for @sinetek (see #3) Can you try a more recent commit (like 61fd606 or d2e2308)?
I just tried 61fd606 and d2e2308, both patched the images without any error, but with them the computer doesn't power up at all anymore (no light, not even the red led when the AC is plugged in).
Try removing all power (cord+batteries) for 1 minute to trigger a ME reset in case that's the problem. Otherwise, it might be helpful to upload the working and non working SPI dumps somewhere temporarily to verify their data. Maybe you are doing something wrong when flashing back.
I don't think the issue is the ME reset because I always disconnect the AC and the battery when I flash.
The SPI in the X1 is a MX25L12873F. It is not supported in flashrom, but it is detected as a generic SPI with the correct size. Reading from it seems to work (the dump looks good, idftool finds and extract the flashregions, me_cleaner patches the intel_me region without error), and writing seems to work also (after testing the patched images, when I write back the original dump the computer works again). Maybe the issue is not with patched images but with the SPI chip (in the specifications I see it has a protected region with OTP). With the same tools I successfully reflashed a Lenovo X200s (where you have to solder onto the WSON chip) and a X200 with libreboot (disabling the ME), but both SPI chips were fully supported in flashrom.
Also, by comparing dumps, I found out that the content of the SPI is changed automatically (during boot?). If I flash the original dump I made, when I read it back, it's the same. But if I boot the computer, and then, read it again, the image is different.
I can upload the dump and patched images if someone want to have a look at them.
Well if you can write some data and read it back right away properly (same hash) then flashing is not the problem. I was talking about wrong SPI image recreation or accidental flashing of the ME region at the entire SPI chip or similar. I'd like to look at whatever dumps and patched images you have to rule out the aforementioned issues and more.
It's perfectly normal for the SPI contents to vary from dump to dump as the BIOS and ME change some of their data depending on the specific system, settings, statuses, reports etc.
I've uploaded the original dump and the 2 patched images I used for my tests (commits 61fd606 and d2e2308) here : X1-roms.zip
They look fine as far as SPI structure and me_cleaner are concerned. Try the test files here just in case. Flash only "test_61fd606_effs.bin" and if it doesn't work there is no need to test the others at all.
Thank you for the test files. I've tried test_61fd606_effs.bin, but like my first try with the initial commit 0bf14b8, the keyboard lights up briefly then the computer shuts down and nothing is displayed on the screen.
Thanks for the report. This looks like some sort of OEM/BIOS security measure to me. Maybe a TPM, BootGuard etc but I don't have knowledge on these subjects. I believe that a modification is detected and the system does not boot. Honestly, if me_cleaner works at ME8, it should work at 9.0-9.1-9.5 and 10.0 as the structure remained the same before Skylake (11.x). And since corna reported 61fd606 as working at a system with ME9.5, this looks like a system-specific problem or security measure.
Thanks for the help and the report. I still don't know if Boot Guard covers the ME region, I will investigate.
Btw, me_cleaner appears to work also with 11.x (as the module structure has changed, but the overall partition structure is the same), and @Nimayer tested it on a desktop PC with Skylake (see #3)
It could be BootGuard related. BG is set via the ME. That machine has Profile 4 (FVE) activated which means "Verified Boot, Immediate Shutdown". So after the reflash, the VB fails and the system is shutdown immediately. Maybe if dnicolier first disables BootGuard via Intel's Flash Image Tool, flashes the ME back with BG disabled and then dumps+me_cleaner+reflash, it may work? There was a great ZeroNights2016 presentation done in November about BootGuard by Alexander Ermolov but I cannot find a public link to download the presentation. It's a good read though.
Hi! I'm Alexander (@platomav have mentioned me above and invited to this conversation). As far as I can tell, this issue may well be Intel Boot Guard related.
Not because of the BG is configured to verify the Intel ME firmware (it's pointless because the verification procedure in ME ROM protects ME firmware well enough). Indeed, the BG manifests in your BIOS contain hash of C 0000h bytes from address FFF4 0000h, it is the only PEI volume in your BIOS.
The most probable reason is that Intel ME being an important part of Intel BG technology. And in case the BG is enabled on the platform, if ME is not operating normally the system will behave according to the BG policy. @platomav have already noticed that your ME region contains the profile 4 (FVE) configuration (enforcing an immediate shutdown). But this area is only a temporary storage for the BG configuration: the ME committing it to the Field Programmable Fuses (FPFs) upon receiving the end of manufacturing message through HECI (the FPFs are one-time programmable, so the system OEM should perform this action for permanent disabling or enabling the BG technology).
So the first action we should do is to check the real BG configuration of your platform. Would you kindly restore the original SPI flash contents and run the Intel MEinfo 9.5.x (run as an administrator)? Please, provide here the information it prints on the screen. You can get the Intel System Tool Kit (which includes this utility) here.
Hi Alexander ! Thank you for your insight. Here's the information provided by MEinfo 9.5 (with the original flash) : MEinfo9.5.txt
Ok, thanks for the log. The chipset FPF values shows that Intel BG is indeed enabled on the platform. Now let's investigate if that particular technology is preventing the system from booting in your case.
I've extracted your BIOS and saw that OEM's BG support implementation (which is new to me btw) in two PEI modules BootGuardEventLogPei and PlatformStage2Pei somehow detects that ME is not operating normally. So I'm currently analyzing it to see how this happens and could this be avoided.
At this moment it seems to me that ME doesn't perform some expected (BG required) actions. Though I hadn't look for BG-related code in the ME firmware before, I think it lives in the early-phase FTPR code modules which can be executed from ME SRAM (hence, even if ME is in recovery state). All of them are Huffman-compressed and I don't get what's going wrong. However, please, try the initial commit of me_cleaner, that doesn't delete the LZMA-compressed modules from FTPR. I will continue reversing the BIOS modules mentioned above.
My first test was with the initial commit 0bf14b8 , the computer behaves differently with the LZMA modules : the keyboard lights up briefly then the computer shuts down (nothing is displayed on the screen). Without the modules it doesn't power up and even the small power/charging led stays off when the AC is plugged.
Hi Alexander and dnicolier, I have a Thinkpad T460s (skylake) and I suspect recent Thinkpads from X1 2nd gen (haswell) onwards may behave in the same way as dnicoliers' does. May it be of any interest here is the MEinfo v11.6 report from my T460s with stock BIOS me_info_t460s.txt
@dnicolier, ok, I'll write here after finishing the analysis. @Nimayer, hi! Thanks for the MEinfo log. Indeed, your laptop also have Intel BG enabled, hence there is a risk of bricking your laptop. So until we find out the exact reason and possible solution I would not recommend you to use the me_cleaner if you are not able to restore the SPI flash contents with a hardware programmer.
Is it possible to develop a tool or functionality integrated in me_cleaner first to detect whether Boot Guard is enabled, in order to avoid unneeded loss, currently?
Yes, to do some reverse engineering of the MEinfo is needed (to extract HECI structures and definitions, related to FPF values request). But until this is done, the simplest way is to run the MEinfo and check the FPFs manually.
For MEI communication, a prime candidate is Igor Skochinsky's @skochinsky me_util script which I suppose can be modified by someone knowledgeable to detect BG-related FPF values.
I haven't looked at the firmware in question but I suspect the cause may be the "Force Boot Guard ACM" mentioned in the log. The ACMs I analyzed rely on the TPM which is implemented in the ME (fTPM module) and possibly the Boot Guard ACM (loaded by the BIOS) fails the boot if TPM is not present. I think it should be possible to modify the initial FPF configuration using Intel's Flash Image Tool to disable Boot Guard and maybe in that case the BIOS will boot normally despite missing TPM. Another option would be to patch the BIOS to skip loading of the ACM or ignore its failure (this needs some RE work though).
The ACMs I analyzed rely on the TPM which is implemented in the ME (fTPM module)
This is a TXT ACM which is loaded by BIOS as part of the Intel TXT technology. Also the BIOS Guard ACM can be found on flash (this one is signed with the same key, which used to sign the microcode updates).
possibly the Boot Guard ACM (loaded by the BIOS) fails the boot if TPM is not present
This is a BG startup ACM which is loaded by the Intel CPU internal boot ROM (microcode ROM) before the RESET-vector (hence, before the BIOS execution) into cache RAM. To do so, CPU finds the Firmware Interface Table (FIT). The pointer to FIT can be found at FFFF FFC0h (mapped flash). This table (FIT) contains entries that points to the BG ACM and to the BG manifests.
So you cannot avoid loading and executing the BG ACM if the BG technology is enabled. You can delete the BG ACM from the flash (or the pointer from FIT), but in case of the "Force Boot Guard ACM" FPF is set, the system will refuse to boot.
If only the "Verified Boot" FPF is set without the "Force..." FPF, then it opens the way to disable BG (just delete BG ACM), but I haven't seen systems with such vulnerable configuration. And I think I won't.
I think it should be possible to modify the initial FPF
This is impossible as long as these FPFs are one-time-programmable (such as other ME-related FPFs like AES chipset key, debug-disable an others) . The only way is to buy a new motherboard or to replace (re-solder) current chipset with the new ("clean") one.
Very interesting information @flothrone, many thanks!
BTW I had a look at the dumps. The FTPM module is present in the FTPR partition so I guess the boot fails not because TPM is missing...
You're welcome :) If you want to look into this technology more deeply, my slides will be available for downloading soon (December/January) at the ZeroNights conference site. Also there is a whitepaper coming with more detailed look on the BG implementation. And on Intel Boot Guard 2.0.
No, actually, as far as the "Measured Boot" FPF is not set, the BG ACM and other BG-related code shouldn't communicate with the TPM. So there must be another reason. I'm trying to understand what exactly is going wrong by analyzing the BG supporting code inside ME firmware and in the BIOS.
Interesting that the log also says this:
Intel(R) Platform Trust Technology - PRESENT/DISABLED
I'm not sure about this, but as far as I understand, if Intel PTT is disabled, the internal TPM based on ME is disabled, and an external TPM is used if present.
Another thing that puzzles me is the empty "ME" column in the last part of the log. Why would MEInfo be able to retrieve the FPF values (which are managed by the ME anyway) but not the ME settings?
I hope that the infos given by MEInfo are complete, a GNU/Linux is installed on the machine, to get this log I've used the DOS version of MEInfo by booting freeDOS on an USB stick.
For information here's the settings in the BIOS :
- Intel AMT, Intel AT and Computrace are Permanently disabled
- Security Chip : Discrete TPM is selected and disabled
@flothrone I'd really like to understand more about Intel Boot Guard but your slides are not available on the zeronights site (unlike the others). When will they appear?
Hi! Sorry about the delay, I've been pretty loaded up with some work in this month. I'll continue researching this issue about BG at the weekend.
Regarding the slides, I expected them to be published at this Monday and I don't know why the link is still unavailable. So, I'm sending them to you via email.