-
Notifications
You must be signed in to change notification settings - Fork 280
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Effect on Lenovo X1 Carbon Gen2 #6
Comments
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). 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. 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. |
Ok, thanks for the log. The chipset FPF values shows that Intel BG is indeed enabled on the platform. 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. |
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). |
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. |
@dnicolier, ok, I'll write here after finishing the analysis. |
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. |
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).
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.
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:
|
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 :
|
@flothrone |
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. |
Unsure if relevant, but there is a service offering to reset SVP for thinkpads, apparently by bypassing Boot/BIOS Guard then loading their own UEFI fw. |
Trammel gave me an idea why BootGuard could fail when changing the ME even though it's supposed to only protect the boot block: the Lenovo BIOS probably includes the ME hash in the measurements so it fails when ME firmware is changed (though it likely handles official ME updates correctly so there should be a way to have it update the ME hash value somehow...) |
Not sure if it's relevant, but I've flashed an unsigned (modified) BIOS image to my Gigabyte p34v5 (Skylake) (which I suspect might have BootGuard enabled) using the "Intel ME System Tools v11". This allowed me to access otherwise hidden menus in the BIOS settings where I've found a toggle to "disable" ME. After doing so, the system information in the BIOS lists ME version as 0.0.0.0 and lspci doesn't show a MEI controller. Furthermore, the intelmetool reports "MEI not hidden on PCI, checking if visible MEI device not found". |
Can you add support for dumping bootguard's FPF config ? It's part of ME, not sure which partition, but can be easily found when changing Intel BG config using Intel's fitc.exe. |
@siro20 well, if it's "easily found", why don't you try to figure out where exactly it is? |
@skochinsky It seems resonable, we would need another non-Lenovo platform with Verified Boot to check it. @sa6097 @siro20 I had used Intel FIT to set Boot Guard in a dump and checked the diff between the image with Boot Guard disabled and the one with Verified Boot, but I didn't find its exact position. If you find the position of that configuration please share it, I'll add the support in me_cleaner. |
@corna one thing that we can possibly check is to clean an ME update image as opposed to the full region then use fwupdcl to flash it using the ME itself. This is likely a supported scenario so in theory should update all related hashes for a successful boot. |
@skochinsky Such a thing will not work. Either FWUpdate or the ME itself will reject the image as corrupted. It requires both FTPR and NFTP to exist at the UPD image and it does check RSA, Hashes and Code length. |
@dnicolier I think it does work with |
@corna It works with And MEInfo can't communicate with the ME anymore :
Thank you ! |
So is this basically confirmation that the AltMeDisable bit trick works on Boot Guard systems? If so, this should be incorporated into the Wiki. |
@flothrone
|
@flothrone Hello, are you still active on here? |
How can I help? |
@flothrone I shot you an @ on Twitter, but I would like some clarification and help regarding Boot Guard/BIOS Guard if you wouldn't mind? i purchased a Lenovo ThinkStation P360 to use as a server, and bought a 13th gen Intel processor for it as it comes with only 12th gen. Apparently Lenovo will not add CPU support for 13th gen since they are releasing a new P3 line for 13th gen so I wanted to add CPU microcode support from the new line of computers to mine (as they are basically the same machine). I dumped my BIOS and inserted the microcode as the volume had enough space, however when trying to flash it back with Intel Flash Programming Tool, I got an error saying Flash Protected Range Registers are set. After doing a lot of research, I used ifdtool to set the HAP bit on my Flash Descriptor to neutralize ME thinking this would solve the problem, but it didn't. After more research, I guess there are some VarStore variables hidden in the BIOS that enable FPRR so I used a setup_var.efi package to modify them on runtime and set BIOS Lock and Enable Flash Protection Range Registers to 0x0, however upon reboot there must be some anti-tamper mechanism because when I get to my BIOS splash screen, the screen goes black and reboots, and then the variables I modified are back to default. Trying to do this another way, I looked into using AMI's flash utilities to flash my BIOS, however those utilities give me an error that BIOS Guard is enabled so the flash couldn't be loaded to memory. This is one of the things I am confused about as I thought setting the HAP bit and neutralizing ME would disable Boot Guard/BIOS Guard? I have spent weeks researching information and feel like I have tried everything and am so close to being able to flash the modded BIOS; I just want to use the CPU I already purchased😭 Do you have any recommendations or advice on what I can do? I tried using MEInfo but it says ME is disabled so I can't see Measured/Verified Boot values. Would a hardware programmer work or would Boot/BIOS Guard brick my SPI and stop it from booting if I flashed the modded BIOS? I would prefer to keep this software-only if possible as my SPI chip is WSON8 so I would need to de-solder it to flash it if thats even possible with BIOS Guard. I have been messaging so many people and its hard to get help from someone knowledgeable in this area, so I wouldn't mind compensating you for your time if you can help me. If you would rather not post any recommendations in public here you can email me at cdmarti12 at gmail dot com. Thanks so much in advance for any help if possible!
|
@flothrone Can you please give me any advice? I'm pulling my hair out trying to load a modified BIOS. I might just resort to a hardware programmer. Will a modified BIOS not load due to Boot Guard? If that's the case, then is my only option replacing the PCH chipset with one that doesn't have the FPF fuses burned in with the vendor signing key/hash? |
Hello, Chris
Firstly, where exactly did you place the microcode in the flash? You have to insert it only where the other MCUs are located, afair this space usually is not covered with Intel Boot Guard (BG) verification. If you insert it randomly in any volume with free space - most likely the BG's verification will fail on this volume. Btw, did you also add an entry to FIT (Firmware Interface Table), so the CPU could take it before running any code? Regarding the Flash Protected Range Registers message, you get this when you try to update only BIOS section, right? In this case it means that PRx are set and the flash is read-only atm. The alternative to this technology is Intel BIOS Guard (BiG) (OEMs usually use either PRx or Intel BiG). The only way to update BIOS is to use the vendor-provided BIOS update tool, which updates BIOS with a signed image via reboot (in case PRx are set) or via BiG update packages (also signed). Hence, the hardware programmer is the only choice. With it you have to care only about not breaking the Boot Guard verified space.
This is expected, the High Assurance Platform bit is checked by ME (to disable itself) after all BG-related routines in ME are finished. So this won't influence on BG in any way.
It won't believe me.
Disable the HAP back again to let ME work during runtime.
It could work, if there are no hardware restrictions for the current PCH to support 13th gen CPUs and if you don't modify the area protected by Intel Boot Guard.
If you modify the area covered with the BG verification - the system won't boot.
If the trick with placing the right MCU and adding the FIT entry won't work - I would suggest selling the system or switching to 12th gen rather then searching for the brand new PCH with "clean" fuses :) |
@flothrone Thank you for the detailed reply, wow! In UEFITool, the microcode section is in a blue highlighted area, which from what I understand means its in a BG protected range. However when opening the BIOS in UEFITool, the microcode header is not within the "a:b" range that is said to be protected by Boot Guard. The range is something like 130000h:FF220000h as shown by UEFITool and the Microcode header is FF2Bxxxxh (can't remember exactly). Regarding FPx, I do get that when trying to flash the BIOS section only, correct. However that happens after I modified the DESC region so that RW access to all regions is 0xFFF, which is why I tried modifying the NVRAM variables to disable FPx but the BIOS resets itself for some reason when modified. And that FPx error happens even when doing a fresh BIOS dump and trying to flash back the fresh dump without modifying anything. You don't think it would be worth buying a PCH off of AliExpress without anything flashed to FPF? I found one pretty easily and messaged the seller to confirm its clean, just havent had a reply yet. I just feel at this point since I put so much effort in I want to get it working, but it may be best to just sell the CPU and get a 12th gen probably. Thanks for your assistance so much, I really appreciate it! I'll see what advice you have to say regarding this latest reply before I decide what to do. All the best, |
You're welcome! :) Correct, MMTool should do the trick.
If you share the image with me, I could double-check. Maybe it is better to place the MCU for 13th gen to some other place in BIOS region which is not covered by Intel BG and to make the according FIT entry to point this place. Because if your MCU no matter partially or fully touches the area covered by BG - the verification will be failed and the system won't boot. What happens on BG fail event actually depends on the configuration in FPFs however when vendors enable Intel BG in Verified Mode they usually set Enforcement Policy = 3 (shutdown immediately). At least I've never seen the configuration allowing to execute a modified IBB.
Well I've never tried replacing the PCH with the new one, because I don't have soldering station powerful enough (IR f.i.) to remove and then to solder back big BGA packages :) But this actually could help you to get rid of Intel Boot Guard on the system. Maybe you will need to change the Flash Descriptors region to make it look like Manufacturing Mode is still on additionally - because I think on a new PCH it is not closed. Maybe even take the "clean" ME image from win-raid forum. Just in case so the new ME will run the firmware without "artefacts" from the previous chip. Still I'm not 100% sure the trick with replacing PCH would work because there can be other issues on this way, such as the requirement to use maybe the newer ME firmware version (not supported by this PCH) to enable the support of 13th gen CPU or there are some other things we don't know about the compatibility between this chipset and 13th gen. @platomav What do you think about this idea? @chrisdma If you decide to walk this road of experiments - let's keep in touch, please, I'm very curious about the result :) |
Interesting, I didn't know it could be essentially anywhere in the BIOS as long as there's a FIT entry pointing to where its at. Attached is my BIOS I dumped using
If this above suggestion doesn't work (adding the microcode to another volume and adding a corresponding FIT entry) then I think I might give it a go. The PCH chipset is only like $60 so I think it would be worth trying out just to see if it works, as the new Lenovo P3 ThinkStations are essentially the exact same machines as the P360 I currently have; Same motherboard layout, same chipset, same everything aside from support for 13th gen processors, so I think it should be very much possible to do. There is already a BIOS release for the new P3 workstations on Lenovo's website, and I downloaded and opened this BIOS in UEFITool and it has the same motherboard model/revision strings as my workstation, which is "330e". I even attempted to flash that BIOS but of course it didn't work as the GUID in the BIOS didn't match my workstation's firmware. As its a signed BIOS capsule update, I wonder if it would be possible to modify my BIOS to match the GUID/firmware of the P3 BIOS and flash it also... |
Thank you for sharing the image, I will take a look a bit later.
If I recall correctly there is a restriction due to CPU caching like all MCUs, BG ACM and FIT should be within the first MegaByte in the flash - but I could be wrong here.
If you figure out how to disable PRx or Intel BIOS Guard or abuse the Lenovo BIOS update procedure with your modified image (bypassing signature checks), feel free to report Lenovo a security advisory with the how-to guide. Because this would be a high-impact vulnerability :) Btw are you able to read the MSR 110h register? With CHIPSEC or something else. Just to make sure that Intel BiG is on? In this case, you will read value 3 (ENABLE and LOCK flags) from this register.
In this case chances are very high IMO. Especially if you take the MCU image for 13th gen CPU from this "new" machine that supports this generation out of the box.
The information about target machines for the firmware could be inside the capsule as well, and this check won't be passed. However it is certainly worth trying. |
Not sure about this, however yesterday when I took of my ME_DISABLE jumper it reset my ME FW back to defaults, and using MEInfo told me that Measured and Verified Boot were both enabled. I believe that should ensure that Boot Guard is enabled, sadly. If I get a hardware programmer then I should be able to flash the BIOS regardless of the FPx. I think this may be worth trying, I just have to figure out where I can put the microcode outside of the BG protected range so it can properly load. |
Regarding the 110h MSR, I meant Intel BIOS Guard (BiG), not the Boot Guard (BG) :D
100% |
I was thinking UEFITool's parsing should be the issue.
Correct, this mean you could proceed with adding 13th gen MCU to the Microcode file.
Intel Boot Guard will check only what's described as the IBB area in "Security" tab on the right from the "FIT" tab. Intel Boot Guard verifies the firmware to protect the device from running modified (non-genuine) firmware in case an attacker managed to write the modified firmware image on the SPI flash memory: with a hardware programmer or somehow from the boot time / runtime (via vulnerability). |
Not at all! Sure, I will look forward to hear back from you! |
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
The text was updated successfully, but these errors were encountered: