Jump to content

CFGLock - unlock (MSR 0xE2)

Brumbaer

By Brumbaer,
in UEFI

 Share
99 posts in this topic

Recommended Posts

  • 2 weeks later...
MacKonsti
MacKonsti
Posted
Posted

Hello @Brumbaer I wanted, too, to thank you for your EFI work and excellent tool, I was looking around to get my hands on it while the answer was right in front of me :D

Is there some kind of versioning for your tool? The last one you released here, I see is June 1st 2020 in your ZIP file shared.

Anyway I was surprised that it unlocked the CPU Cfg on my NUC10i7FNH hack! Thank you.

Link to comment
Share on other sites
  • 2 weeks later...
MacKonsti
MacKonsti
Posted
Posted (edited)

Hello again @Brumbaer and everyone, hope you're all well and safe.

So with the June release of CFGLock.efi found in the previous page, I was able to unlock the MSR Ex02 of my CPU on the NUC10i7FNH2 Hackintosh.

 

However, when I tried the same process with the same boot USB on the NUC8i7BEH2 hack, there is a message that there was no "cfg entry" found in NVRAM.

So I guess that for that NUC, Intel's firmware is using some custom name for the CPU CfgLock, yes? Because VerifyMsrE2.efi does report the CPUs being locked.

 

Is there some "debug" parameter we can add to OpenCore's config.plist to allow for more details on what was found, perhaps, @Brumbaer ? Just curious really to see what is registered by the firmware (no BIOS entry for CPU Lock of course).

Thank you again for your work.

Edited by MacKonsti
  • Like 1
Link to comment
Share on other sites
  • 1 month later...
pmjohann
pmjohann
Posted
Posted
On 6/1/2020 at 2:05 PM, Brumbaer said:

Some boards do not have a visible option for CFG Lock.

For those cases the Bootloaders offer options to not write to the MSR. An other way is to disable CFG Lock in the BIOS despite the fact that there is no option available in the user interface.

One way to do so is to use UEFITool, ifrextract and a patched Grub. Which is not only cumbersome, also it will work only, if the storage used for CFG Lock is in a certain varstore.

Generally speaking CFGLock.efi does what those tools do, but the only user interaction needed is to confirm that you want to toggle the CFG Lock value (on to off/off to on) and it works regardless where the CFG Lock option resides, as long as the BIOS has a CFG Lock option - hidden or not - in their HiiDatabase.

It is an EFI Application. Install it in the Tools folder of your OpenCore EFI and enter it under Misc->Tools in the config.plist.

The EFI must not be able to boot MacOS, it must just be able to show the picker.

It should also run as an application from the UEFI shell, but I haven't tested this.

CFGLock.efi.zip

Hi there,

The download link is dead unfortunately.

Could you re-upload please?

Thank you!

Link to comment
Share on other sites
  • 3 weeks later...
MacKonsti
MacKonsti
Posted
Posted (edited)

Hi everyone, is there some versioning or version tracking? Or are we based on date only?

It's a shame that @Brumbaer is no longer active, his work is amazing, I wish he could just drop by from time to time.... anyone has news? Is he/she doing well?

 

UPDATE: Thanks @1Ale1 for sharing this compiled Tool from OC, appreciate it, as I could not find it anywhere (yet).

Edited by MacKonsti
Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted (edited)

Hi again everyone, thanks again @1Ale1 for the EFI file, are you able to compile from sources?

I tried on my NUC and on the second attempt, it freezes :blush:

After adding your shared ControlMsrE2.efi to /Tools/ folder, I added to my config.plist: 

			<dict>
				<key>Arguments</key>
				<string></string>
				<key>Auxiliary</key>
				<true/>
				<key>Comment</key>
				<string>Control MSR Lock</string>
				<key>Enabled</key>
				<true/>
				<key>Name</key>
				<string>Control MSR Lock</string>
				<key>Path</key>
				<string>ControlMsrE2.efi</string>
				<key>RealPath</key>
				<false/>
				<key>TextMode</key>
				<false/>
			</dict>

Without "Arguments" on first run it said that it's running in VERIFY mode and worked fine. The options are apparently lock or unlock or interactive
Next, I added interactive as arguments to see how it works and what it looks for in my EFI NVRAM, this way: 

			<dict>
				<key>Arguments</key>
				<string>interactive</string>
				<key>Auxiliary</key>
				<true/>
				<key>Comment</key>
				<string>Control MSR Lock</string>
				<key>Enabled</key>
				<true/>
				<key>Name</key>
				<string>Control MSR Lock</string>
				<key>Path</key>
				<string>ControlMsrE2.efi</string>
				<key>RealPath</key>
				<false/>
				<key>TextMode</key>
				<false/>
			</dict>

So when I selected it at boot time, it did run but then the computer froze (no keyboard input or anything at all) when it asked me to confirm with some letter Y or N not sure.

How do you guys run this new ControlMsrE2.efi yourselves?


If there's a new compiled from sources (as I see some more changes these last days) a ZIP file would be appreciated... Thanks!

 

UPDATE: Seems this ControlMsrE2.efi is (still?) a debug version, same one as @1Ale1 shared exists officially in the OpenCoreDebug package 0.6.5 https://github.com/utopia-team/opencore-debug/releases/tag/0.6.5

Edited by MacKonsti
Link to comment
Share on other sites
  • 1 month later...
  • 2 weeks later...
MacKonsti
MacKonsti
Posted
Posted (edited)

I have downloaded https://github.com/utopia-team/opencore-debug/releases and it works fine with OpenCore 0.6.6 just tested it as I updated my NUC10 BIOS and MSR was re-locked.

Not sure how BOOTx64.efi is related @BuXb to be honest.

But better run it through interactive UEFI Shell.

 

Edited by MacKonsti
Link to comment
Share on other sites
  • 2 weeks later...
deeveedee
deeveedee
Posted
Posted
On 12/1/2020 at 3:25 AM, MacKonsti said:

However, when I tried the same process with the same boot USB on the NUC8i7BEH2 hack, there is a message that there was no "cfg entry" found in NVRAM.

So I guess that for that NUC, Intel's firmware is using some custom name for the CPU CfgLock, yes? Because VerifyMsrE2.efi does report the CPUs being locked.

 

Does the "new" ControlMsrE2 (apparently being released with OC 0.6.8) work on your NUC8?

Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted (edited)

Hi guys, so @tonyx86 I added this new (and latest) ControlMsrE2 in the EFI partition, rebooted (r5131) and selected UEFI Shell. Ran it (manually in the shell). Seems to work OK (no freezes I mean, "interactive" works it seems). The other tool VerifyMsrE2 works too, actually I ran that one first just to be safe.

 

However, NUC8 doesn't have any trace of "cfg" or "msr" in the region that ControlMsrE2 is looking at. My NUC8 remains locked. I think this is due to the fact that the BIOS comes from Intel and they may have hidden it completely. 

 

Thanks @BuXb but on my NUC I still cannot find any parameter or string that would prompt to MSR 0xE2 CFG Lock; I saw your Git Hub page, but not sure what you're prompting me to look for? Clearing NVRAM and restarting doesn't have any effect, really.

Edited by MacKonsti
Link to comment
Share on other sites
BuXb
BuXb
Posted
Posted
8 hours ago, MacKonsti said:

@BuXbnot sure what you're prompting me to look for?

"Right after turning on or rebooting your VivoBook [/your hackintosh], press the ESC key [or equivalent] to intercept booting and to enter the built-in Boot Menu. THIS STEP IS MANDATORY [at least on Asus VivoBook S15] so CFGLock.efi [and ControlMsrE2] can find the CFG variable if run as a tool from within Clover - DON'T SKIP IT!
"

Link to comment
Share on other sites
MacKonsti
MacKonsti
Posted
Posted

Hi mate, thanks for the clarification but I fail to see how different is running the CFG tool from UEFI Shell of Clover, and an entry as Tool (that I have never tried in my life). So by ESC key you mean access the Clover menu, yes @BuXb?

I have a time-out of 10 seconds in all my machines (i.e. no direct boot) so I always access Clover menus etc. However, I believe that the Visual BIOS from Intel just has no setting and it's not available in the firmware's NVRAM that CFGLock.efi [and ControlMsrE2] access (that is my impression)... or they masked it very well to some crazy-Intel-internal wording....

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...