Effect on Lenovo X1 Carbon Gen2

[dnicolier]

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

[corna]

It works for @sinetek (see #3)
Can you try a more recent commit (like 61fd606 or d2e2308)?

[dnicolier]

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).

[platomav]

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.

[dnicolier]

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.

[platomav]

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.

[dnicolier]

I've uploaded the original dump and the 2 patched images I used for my tests (commits 61fd606 and d2e2308) here : X1-roms.zip

[platomav]

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.

[dnicolier]

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.

[platomav]

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.

[corna]

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)

[platomav]

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.

[flothrone]

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.

[dnicolier]

Hi Alexander ! Thank you for your insight.
Here's the information provided by MEinfo 9.5 (with the original flash) : MEinfo9.5.txt

[flothrone]

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.

[dnicolier]

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.

[f-izzo]

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

[flothrone]

@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.

[persmule]

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?

[flothrone]

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.

[platomav]

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.

[skochinsky]

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).

[flothrone]

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.

[skochinsky]

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...

[flothrone]

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.

[skochinsky]

Interesting that the log also says this:

Intel(R) Platform Trust Technology - PRESENT/DISABLED

[flothrone]

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.

[skochinsky]

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?

[dnicolier]

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

[corna]

@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?

[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.

[5685C4A059D5]

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.
It's a paid service, but their (very limited) info page may provide some hints: Info

[skochinsky]

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...)

[sa6097]

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".

[siro20]

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.

[skochinsky]

@siro20 well, if it's "easily found", why don't you try to figure out where exactly it is?

[corna]

@skochinsky It seems resonable, we would need another non-Lenovo platform with Verified Boot to check it.

@sa6097 intelmetool can't detect yet a disabled ME on Skylake. I think you don't have Intel Boot Guard in Verified Boot mode, can you check it with this guide?

@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.

[skochinsky]

@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.

[platomav]

@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.

[corna]

@dnicolier I think it does work with me_cleaner -s, can you try it?

[dnicolier]

@corna It works with me-cleaner -s. The X1 boots with the modified firmware (without any issue).

And MEInfo can't communicate with the ME anymore :

Intel(R) MEInfo Version: 9.5.35.1850
Copyright(C) 2005 - 2014, Intel Corporation. All rights reserved.
Error 9256: Communication error between application and Intel(R) ME module (FW Update client)
Error 9459: Internal error (Could not determine FW features information)

Thank you !

[lauhayden]

So is this basically confirmation that the AltMeDisable bit trick works on Boot Guard systems? If so, this should be incorporated into the Wiki.

[DasPez]

@flothrone
Hello, I wanted to share the ME configuration of my Dell Inspiron 7559.

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.

Intel(R) MEInfo Version: 11.0.26.3000
Copyright(C) 2005 - 2017, Intel Corporation. All rights reserved.



Intel(R) ME code versions:

BIOS Version                                 1.2.4
MEBx Version                                 0.0.0.0000
GbE Region does not exist.
GbE Version                                  Unknown
Vendor ID                                    8086
PCH Version                                  31
FW Version                                   11.0.17.1002 H
LMS Version                                  11.0.0.1173
MEI Driver Version                           11.0.0.1176
Wireless Hardware Version                    2.1.77
Wireless Driver Version                      19.50.1.6

FW Capabilities                              0x31111940

    Intel(R) Capability Licensing Service - PRESENT/ENABLED
    Protect Audio Video Path - PRESENT/ENABLED
    Intel(R) Dynamic Application Loader - PRESENT/ENABLED
    Intel(R) Platform Trust Technology - PRESENT/ENABLED

TLS                                          Disabled
Last ME reset reason                         Firmware reset
Local FWUpdate                               Enabled
BIOS Config Lock                             Enabled
GbE Config Lock                              Enabled
Host Read Access to ME                       Disabled
Host Write Access to ME                      Disabled
Host Read Access to EC                       Enabled
Host Write Access to EC                      Enabled
SPI Flash ID 1                               EF4016
SPI Flash ID 2                               EF4017
BIOS boot State                              Post Boot
OEM ID                                       00000000-0000-0000-0000-000000000000
Capability Licensing Service                 Enabled
OEM Tag                                      0x00000000
Slot 1 Board Manufacturer                    0x00000000
Slot 2 System Assembler                      0x00000000
Slot 3 Reserved                              0x00000000
M3 Autotest                                  Disabled
C-link Status                                Disabled
Independent Firmware Recovery                Disabled
EPID Group ID                                0xF87
OEM Public Key Hash FPF                      44DE8298FD30B55CFB22E3CFA6B5AE6F6B8C250165C2542BC56E45BC01AF1284
OEM Public Key Hash ME                       44DE8298FD30B55CFB22E3CFA6B5AE6F6B8C250165C2542BC56E45BC01AF1284
ACM SVN FPF                                  0x2
KM SVN FPF                                   0x0
BSMM SVN FPF                                 0x0
GuC Encryption Key FPF                       0000000000000000000000000000000000000000000000000000000000000000
GuC Encryption Key ME                        0000000000000000000000000000000000000000000000000000000000000000

                                             FPF                      ME
                                             ---                      --
Force Boot Guard ACM                         Disabled                 Disabled
Protect BIOS Environment                     Enabled                  Enabled
CPU Debugging                                Enabled                  Enabled
BSP Initialization                           Enabled                  Enabled
Measured Boot                                Enabled                  Enabled
Verified Boot                                Enabled                  Enabled
Key Manifest ID                              0x1                      0x1
Enforcement Policy                           0x1                      0x1
PTT                                          Enabled                  Enabled
PTT Lockout Override Counter                 0x1
EK Revoke State                              Not Revoked
PTT RTC Clear Detection FPF                  0x0

[chrisdma]

@flothrone Hello, are you still active on here?

[flothrone]

How can I help?

[chrisdma]

@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!

• Chris

[chrisdma]

@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?

[flothrone]

Hello, Chris

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.

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.

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.

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.

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?

It won't believe me.

I tried using MEInfo but it says ME is disabled so I can't see Measured/Verified Boot values

Disable the HAP back again to let ME work during runtime.

Would a hardware programmer work or would Boot/BIOS Guard brick my SPI and stop it from booting if I flashed the modded BIOS?

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.

Will a modified BIOS not load due to Boot Guard?

If you modify the area covered with the BG verification - the system won't boot.

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?

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 :)

[chrisdma]

@flothrone Thank you for the detailed reply, wow!
Regarding the FIT table, I used MMTool to addd the microcode so it adjusted the FIT accordingly; and it was added to the same volume as the other microcode with enough free space in the volume so MMTool made the necessary adjustments automatically.

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,
Chris

[flothrone]

You're welcome! :)

Correct, MMTool should do the trick.

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).

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.

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.

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 :)

[chrisdma]

@flothrone

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.

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 fptw64 -BIOS -d baseBIOS.bin.
baseBIOS.zip
I'll have to look into how I can do this, because if I can insert the microcode anywhere there's enough space in the volume and load it then that would be awesome to try out. The issue would be figuring out how I can flash the whole BIOS image since FPx disables all BIOS flashing from software; if I can't figure out how to disable the protected registers in NVRAM and make them stick, I think ill need to use a hardware programmer to dump the BIOS and reflash it.

@chrisdma If you decide to walk this road of experiments - let's keep in touch, please, I'm very curious about the result :)

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...

[flothrone]

Thank you for sharing the image, I will take a look a bit later.

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.

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.

The issue would be figuring out how I can flash the whole BIOS image since FPx disables all BIOS flashing from software; if I can't figure out how to disable the protected registers in NVRAM and make them stick, I think ill need to use a hardware programmer to dump the BIOS and reflash it.

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.

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.

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.

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...

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.

[chrisdma]

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.

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.

[flothrone]

Regarding the 110h MSR, I meant Intel BIOS Guard (BiG), not the Boot Guard (BG) :D

If I get a hardware programmer then I should be able to flash the BIOS regardless of the FPx.

100%

[chrisdma]

Regarding the 110h MSR, I meant Intel BIOS Guard (BiG), not the Boot Guard (BG) :D

If I get a hardware programmer then I should be able to flash the BIOS regardless of the FPx.

100%

Okay ill build CHIPSEC and give that a go.

What is interesting is Nikolaj Schlej happened to reply back to me regarding this as well, and he said that while UEFITool colors the microcode section as being within the BG protected range, it actually isn't according to the checkProtectedRanges function as seen below:

He said this is due to UEFITool detecting the AMI hash file as v2 using its size as a heuristic, while its actually v3 but only has 2 hash entries where v3 normally has 3, and that Boot Guard doesn't actually cover the microcode volumes.

With that being said, does this mean I can modify the MC volumes as I originally wanted to, flash the BIOS, and it'll load correctly? Or does Boot Guard/BIOS Guard (not sure what the differentiation is) check the whole BIOS hash and if its modified then it can't load?

[flothrone]

I was thinking UEFITool's parsing should be the issue.

With that being said, does this mean I can modify the MC volumes as I originally wanted to, flash the BIOS, and it'll load correctly?

Correct, this mean you could proceed with adding 13th gen MCU to the Microcode file.

Or does Boot Guard/BIOS Guard (not sure what the differentiation is) check the whole BIOS hash and if its modified then it can't load?

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).
Intel BIOS Guard protects the firmware from being modified from the boot time / runtime, almost like PRx (Protected Ranges) - but the mechanism is different.

[chrisdma]

I was thinking UEFITool's parsing should be the issue.

With that being said, does this mean I can modify the MC volumes as I originally wanted to, flash the BIOS, and it'll load correctly?

Correct, this mean you could proceed with adding 13th gen MCU to the Microcode file.

Or does Boot Guard/BIOS Guard (not sure what the differentiation is) check the whole BIOS hash and if its modified then it can't load?

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). Intel BIOS Guard protects the firmware from being modified from the boot time / runtime, almost like PRx (Protected Ranges) - but the mechanism is different.

Awesome! I really didn't want to have to replace the PCH chipset, so looking at the below ranges I think I will be okay, since MC headers are at FFBB03E8h:

I just ordered a hardware programmer and will give this a try! Thanks so much for your help throughout this, I very much appreciate this. I'll keep you updated on how it goes just in case you're curious if I can get it working. :)

Cheers,
Chris

[flothrone]

Not at all! Sure, I will look forward to hear back from you!