Jump to content

CFGLock - unlock (MSR 0xE2)


98 posts in this topic

Recommended Posts

What about Saltwell, between Ivy Bridge and Haswell? Correct as below + "Any OS"? If so then it would be one same line with "Ivy Bridge, Saltwell" (?)

 

And if the E2 lock was first introduced with Nehalem, it should be Penryn & older which includes Core 2 Duo, right?

 

https://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchitectures

 

1786617810_macOSOSXCPUs.png.20524fb2f6943969d2a666157caa6f9b.png

 

Here correct table.

If no msr 0xe2, or msr 0xe2 unlock: any macOS, any CPU, No, No.

On 3/31/2021 at 12:03 AM, Andrey1970 said:

25052776_2021-03-3023_59_24.png.a58c9d4270b67be8e472b310ff83fcff.png

 

Present or no, locked or no, if we set YES then it will be nothing bad.

  • Like 1

Hi @Andrey1970 and everyone, for the clarity of everyone reading your guides etc. can I possibly suggest a slightly better way to set these titles?

 

First table: If MSR 0xE2 (Cfg) lock setting exists in BIOS or can be unlocked (via tool)

Second table: If MSR 0xE2 (Cfg) lock is not present in BIOS or cannot be unlocked (via tool)
 

This way it's more obvious... In my work I try to be explicit and quite explanatory so people avoid asking the same stuff... hope you agree. Thanks.

1 hour ago, MacKonsti said:

Hi @Andrey1970 and everyone, for the clarity of everyone reading your guides etc. can I possibly suggest a slightly better way to set these titles?

 

First table: If MSR 0xE2 (Cfg) lock setting exists in BIOS or can be unlocked (via tool)

Second table: If MSR 0xE2 (Cfg) lock is not present in BIOS or cannot be unlocked (via tool)
 

This way it's more obvious... In my work I try to be explicit and quite explanatory so people avoid asking the same stuff... hope you agree. Thanks.

 

868030016_2021-04-0216_44_35.png.1845c6cf7b2b90be2d56acb79e345c09.png

  • Like 3

As it is necessary to consider that in certain cases MSR 0xE2 unlocking by vendor default аnd settings in BIOS are absent.

For an example: GigaByte Z77, Z87

  • Like 3

As I've reported earlier, VerifyMsrE2.efi reports my MSR 0xE2 as locked and ControlMsrE2.efi can't find CFGLock.  Could it be that my MSR 0xE2 is unlocked, but it's simply not visible to VerifyMsrE2  and ControlMsrE2?  Does VerifyMsrE2 report MSR 0xE2 as "locked" if it can't find it?  Details below.

 

I'm currently booting my rig with OC 0.6.7 (Both Catalina 10.15.7 and Big Sur 11.2.3).  VerifyMsrE2 reports my MSR 0xE2 as locked.  ControlMsrE2 can't find my MSR 0xE2 to unlock it.  I've attempted to examine my BIOS.bin with UEFITool / Universal IFR Extractor but can't find the required SETUP region for MSR 0xE2 (same as @MacKonsti reported for his NUC8).  With CLOVER r5122 (Catalina), I needed KernelPm patch enabled in order to boot.  With OC 0.6.7, I'm finding that I don't need AppleCpuPmCfgLock or AppleXcpmCfgLock enabled to boot.  

 

  1. If VerifyMsrE2 reports MSR 0xE2 as locked, could that be a false reading if VerifyMsrE2 can't find MSR 0xE2?
  2. If CLOVER r5122 required KernelPm to boot, does that necessarily mean that my MSR 0xE2 is locked?
  3. If OC 0.6.7 doesn't need either AppleCpuPmCfgLock or AppleXcpmCfgLock enabled, does that mean that my MSR 0xE2 is unlocked?
Edited by tonyx86
3 hours ago, tonyx86 said:

.  

 

  1. If VerifyMsrE2 reports MSR 0xE2 as locked, could that be a false reading if VerifyMsrE2 can't find MSR 0xE2?
  2. If CLOVER r5122 required KernelPm to boot, does that necessarily mean that my MSR 0xE2 is locked?
  3. If OC 0.6.7 doesn't need either AppleCpuPmCfgLock or AppleXcpmCfgLock enabled, does that mean that my MSR 0xE2 is unlocked?

1. Provide Clover's preboot.log to resolve "false reading"

2. There may be other reasons to not boot but if KernelPM is the key then it really means the register is locked.

3. I don't know how it can be.

 

Again. Show please Clover's preboot.log (by type F2 key).

1 hour ago, Slice said:

1. Provide Clover's preboot.log to resolve "false reading"

2. There may be other reasons to not boot but if KernelPM is the key then it really means the register is locked.

3. I don't know how it can be.

 

Again. Show please Clover's preboot.log (by type F2 key).

@Slice I'm booting with OC 0.6.7 now - hard to go back to CLOVER, but I can reference old debug logs.   I last captured the attached F2 preboot.log in CLOVER r5122. My CLOVER config.plist is also attached.  VerifyMsrE2.efi (OC Tools) reports my MSR 0xE2 as locked.  ControlMsrE2 (OC Tools) cannot find my MSR 0xE2.  I am currently running OC 0.6.7 with AppleCpuPmCfgLock and AppleXcpmCfgLock both false and OC boots Big Sur 11.2.3 and Catalina 10.15.7 without any problems. With KernelPm = false (CLOVER) I could not boot Catalina 10.15.7. 

bootlog.txt.zip config.plist.zip

Edited by tonyx86
9 minutes ago, tonyx86 said:

@Slice I'm booting with OC 0.6.7 now - hard to go back to CLOVER, but I can reference old debug logs.   I last captured the attached F2 preboot.log in CLOVER r5122. My CLOVER config.plist is also attached.  VerifyMsrE2.efi (OC Tools) reports my MSR 0xE2 as locked.  ControlMsrE2 (OC Tools) cannot find my MSR 0xE2.  I am currently running OC 0.6.7 with AppleCpuPmCfgLock or AppleXcpmCfgLock both false and OC boots Big Sur 11.2.3 and Catalina 10.15.7 without any problems. With KernelPm = false (CLOVER) I could not boot Catalina 10.15.7. 

bootlog.txt.zip 10.96 kB · 0 downloads config.plist.zip 2.99 kB · 0 downloads

Clover said 0xE2 is locked.

0:100  0:000  MSR 0xE2 is locked,

Trust me, I am sure it is true because I know what Clover does.

OC can boot without these quirks? It is not true. I don't know how it can happen and may propose the quirks are really true.

The boot without these patches is impossible because the register 0xE2 is locked.

  • Like 1

@Slice I see that CLOVER says it's locked and VerifyMsrE2 says it's locked, too, but I question the result.  I can't find CFG Lock in the BIOS.bin and ControlMsrE2 can't find it.  My OC 0.6.7 config.plist is attached.  This OC 0.6.7 config.plist is what I'm current using to boot Catalina 10.15.7 and BS 11.2.3.  AppleCpuPmCfgLock or AppleXcpmCfgLock are both false.  My rig is defined here.

config.plist.zip

2 minutes ago, tonyx86 said:

@Slice I see that CLOVER says it's locked and VerifyMsrE2 says it's locked, too, but I question the result.  I can't find CFG Lock in the BIOS.bin and ControlMsrE2 can't find it.  My OC 0.6.7 config.plist is attached.  This OC 0.6.7 config.plist is what I'm current using to boot Catalina 10.15.7 and BS 11.2.3.  AppleCpuPmCfgLock or AppleXcpmCfgLock are both false.  My rig is defined here.

config.plist.zip 2.99 kB · 0 downloads

You are confusing two claims. 

First is the MSR register 0xE2 is a part of the CPU. Its value  defined by the CPU.

Second is BIOS has a variable to lock or unlock the register. Not every BIOS has such variable so why ControlMsrE2.efi can't find it.

But the application can see the register no matter if the BIOS has no such setting. See my photo.

Can you show similar photo?

I may propose something else. If OC didn't provide CPU speedstep then it can boot without patching CfgLock.

Clover did provide and it needs to patch CfgLock.

  • Like 1
  • Thanks 1

@Slice - Here you go...

 

Spoiler

IMG_1495.thumb.JPG.b701d977639e9e299049994d484200d8.JPG

 

@Slice If my MSR 0xE2 register is truly locked (and not just invisible to ControlMsrE2), would I observe a kernel panic on every boot, or just on rare instances?  I have been running with AppleCpuPmCfgLock and AppleXcpmCfgLock set to FALSE today and have booted/rebooted 5 or 6 times without problems.  If this is just an intermittent boot issue, then I will need to test longer.

 

EDIT: I don't believe that OC is providing any CPU Speedstep.  I believe that I have my rig running with native macOS CPU Power Management.  I suspect that @Andrey1970 knows this answer better than I do.

 

@Slice You are correct - I was confusing the two concepts.  I did not understand that the CPU register and the BIOS Option were two separate entities.  Now I understand why VerifyMsrE2 and CLOVER can "see" that the CPU register is locked without having access to the BIOS CFG Unlock Option.  Thank you very much for teaching me!

Edited by tonyx86
  • Like 1

Glad to see you have this sorted out now @tonyx86. I believe Intel and HP and perhaps Dell and big makers, do hide the ability to unlock this register from BIOS hence why we can't find any reference of this (unless it's a totally masked variable name only known to the manufacturer!)

On my Clover log (quickly obtained via Hackintool) I do get on my NUC8 (using Intel's own Visual BIOS):

0:103  0:000  MSR 0xE2 is locked, PM patches will be turned on

On my NUC10 that is not using this Visual BIOS but some other variant, the "cfg" variable is found and I can unlock it. Perhaps a choice of the manufacturer or change of heart. But A LOT of manufacturers lock down this darn register without offering a BIOS option.

Why is it, however? Why do they leave it like that? Is it because of how Windows work?

  • Like 1
7 hours ago, MacKonsti said:


On my NUC10 that is not using this Visual BIOS but some other variant, the "cfg" variable is found and I can unlock it. Perhaps a choice of the manufacturer or change of heart. But A LOT of manufacturers lock down this darn register without offering a BIOS option.

Why is it, however? Why do they leave it like that? Is it because of how Windows work?

Windows is more correct than macOS. It checks the register 0xE2 before using while Apple assumes the register is always unlocked on their computers.

  • Like 2
7 hours ago, Slice said:

Windows is more correct than macOS. It checks the register 0xE2 before using while Apple assumes the register is always unlocked on their computers.

 

Damn that Apple!  Don't they know we're trying to run macOS on Windows hardware?  :)

  • Haha 2

@tonyx86 another method I forgot to mention to validate the CFG Lock support is to run AppleIntelInfo.kext and check out the output. There is a mention for that lock thing. The problem is that until Mojave we could run this manually, but after the stricter protection, we need to include it temporarily in our EFI folder and load it in config.plist (if using OpenCore). The original work was done by https://github.com/Piker-Alpha/AppleIntelInfo here, but not sure who took over and continued the work, I could not find a more modern version and reference.

 

In my older NUC8 logs that I recorded (and stored in my repo) there's a clear mention:

MSR_PMG_CST_CONFIG_CONTROL.......(0xE2)  : 0x1E008008
------------------------------------------
 - I/O MWAIT Redirection Enable......... : 0 (not enabled)
 - CFG Lock............................. : 1 (MSR locked until next reset)
 - C3 State Auto Demotion............... : 1 (enabled)
 - C1 State Auto Demotion............... : 1 (enabled)
 - C3 State Undemotion.................. : 1 (enabled)
 - C1 State Undemotion.................. : 1 (enabled)
 - Package C-State Auto Demotion........ : 0 (disabled/unsupported)
 - Package C-State Undemotion........... : 0 (disabled/unsupported)

This is how I used to load it and run it:

sudo kextload AppleIntelInfo.kext
echo "Kext loaded, waiting 600 seconds to terminate..." ; sleep 600
sudo cat /tmp/AppleIntelInfo.dat >> ~/Desktop/AppleIntelInfo.txt
echo "Waiting 5 seconds to unload kext..." ; sleep 5
sudo kextunload AppleIntelInfo.kext

If anyone knows where to find a more modern and/or improved version of Piker's work, please kindly post it? @Slice and @Andrey1970 any idea? Or a signed kext that may run under Catalina?
Thanks

  • Like 1

@Andrey1970 thanks for the updated table - all clear now!

 

to both of you, @Slice also: great information/ teaching/ lesson, I've learned a lot about this topic from both of you ->  :thanks_speechbubble: !

 

×
×
  • Create New...