MP 1,1-5,1 Understanding the OpenCore Data variable settings

[startergo]

So this:

<key>Cpuid1Data</key>
            <data>
            AAAAAAAAAAAAAAAMAAAAAA==
            </data>
            <key>Cpuid1Mask</key>
            <data>
            AAAAAAAAAAAAAAAMAAAAAA==
            </data>

enables XSAVE OSXSAVE:

sysctl machdep.cpu.features                                                       
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 POPCNT AES PCID XSAVE OSXSAVE

Now someone can test the newest VMWARE:

VMWare Fusion no more on MacPro5,1

Parallels 16 runs on Big Sur using KEXTs. VMware 12 uses KEXTs in Catalina, but disables it on Big Sur. So no go on cMP 5,1. I am switching. ==> Updated: Parallels 17 STILL works!

forums.macrumors.com

 

[Dayo]

MouSSE emulates the SSE4.2 (Bit 20) and the POPCNT (Bit 23) features.
Presumably this will spoof support if checked by software?

printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x01\x00\x00\x00\x00" | base64

AAAAAAAAAAAAABABAAAAAA==

 

[startergo]

MouSSE emulates the SSE4.2 (Bit 20) and the POPCNT (Bit 23) features.
Presumably this will spoof support if checked by software?
View attachment 977671

printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x01\x00\x00\x00\x00" | base64

AAAAAAAAAAAAABABAAAAAA==

No use this:

printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00" | base64
AAAAAAAAAAAAAJAAAAAAAA==

 

[Dayo]

Any idea why the features show up when running sysctl machdep.cpu.features but do not show up in MacCPUID?
Was the same with SSE4.2 alone.

Perhaps the program is using a database of features as opposed to taking what the computer reports.

 

[joevt]

No use this:

printf "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x90\x00\x00\x00\x00\x00" | base64
AAAAAAAAAAAAAJAAAAAAAA==

Use xxd -p -r for easier readability (put spaces where-ever you like)

echo "00000000 00000000 00009000 00000000" | xxd -p -r | base64

 

[Syncretic]

Any idea why the features show up when running sysctl machdep.cpu.features but do not show up in MacCPUID?
Was the same with SSE4.2 alone.

Perhaps the program is using a database of features as opposed to taking what the computer reports.

I know nothing about MacCPUID, but I do know a bit about the MacOS kernel. The CPUID instruction is fairly "expensive" in terms of clock cycles, and most of its results are invariant, so the kernel caches them (at startup, it runs through the entire CPUID tree and stores all the values it finds). sysctl reads from that cache, as does almost all of MacOS itself (which is the whole point of caching it in the first place). OpenCore is almost certainly just modifying this cached copy of the CPUID data. My guess is that MacCPUID is actually executing the CPUID instruction, which will return the true CPU results instead of whatever's cached, meaning that OpenCore can't fool it. (I'm only guessing about what OpenCore is doing; I've never looked at the OpenCore code, although that's on the long list of things I hope to get to someday...)

 

[cdf]

There is another confusion for me when you have time please clarify. The manual states when spoofing EAX to set the CPUID1Mask to F when corresponding value is changed and for enabling bits we set both CPUID1DATA and CPUID1MASK to the same value.

Using F would zero out the surrounding bits when changing just one bit.

 

[startergo]

Wonder if there is anything actually fooled by the spoofing considering that MacCPUID also doesn't change what it reports

It looks like it is patching kernel (cache) as suggested by @Syncretic :

OpenCorePkg/Platform/OpenCore/OpenCoreKernelPatch.c at 1b7525c7de2680f49ba0d841f6258c761651844b · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

and MacCPUID reads the registers directly as is VMWARE Fusion. Since it is not an open source there is no way to find out what. If VirtualBox ever imposes similar requirement at least we can inspect the source code.
Chipsec is also able to change the CPU registers. I tested it earlier.

 

[Dayo]

MacCPUID reads the registers directly as is VMWARE Fusion .... Chipsec is also able to change the CPU registers. I tested it earlier.

Most likely some SDK feature or library (maybe something in Xcode) that developers simply call and which bypasses the cache ... maybe not as expensive anymore.

Widespread use will make spoofing on the cache ineffectual and require something more extreme such as that Chipsec thing.

 

[Dayo]

@startergo ... Is AAAAAAAAAAAAAJCAAAAAAA== a valid combination of AAAAAAAAAAAAAJAAAAAAAA== and AAAAAAAAAAAAAACAAAAAAA==?

 

[startergo]

What exactly are you trying to achieve?

 

[Dayo]

Trying to combine vmm with the previous

 

[startergo]

It should be:

echo "00000000 00000000 00009080 00000000" | xxd -p -r | base64
AAAAAAAAAAAAAJCAAAAAAA==

 

[Dayo]

Ok. Same as I had. Just wanted to be sure.
Thanks

 

[Dayo]

Can anyone help with a breakdown of the features contained in the suggested FirmwareFeatures (A1QM4A==) and FirmwareFeaturesMask (P/8f/w==)?

I can see a list of items in the OpenCore Source but trying to know what is on of off in those values that are going in.

Any hints ... @cdf ?

 

[startergo]

Copy the HEX value ( or the converted base64 to HEX) to a calculator App in programming mode in HEX edits, swap the bytes (down on the left) and inspect the binary bits. Compare them to the c file. Each bit in binary has it's corresponding value in HEX, which is what is described in the C file. Same logic as in car rotate file. @joevt had somewhere posted automatic conversion from base64 to binary in groups of 4. I am not sure if it has endianness conversion included .

 

[Dayo]

Thanks. Did that already and still befuddled.

Can't relate FF 1F FF 3F to anything in the file. Guess I must be missing something.

 

[Dayo]

Think I might slowly be getting it. Each of the 32 bits in the calc correspond to the items in the file.

 

[startergo]

Think I might slowly be getting it. Each of the 32 bits in the calc correspond to the items in the file.

Right. For instance:

OpenCorePkg/Include/Apple/IndustryStandard/AppleFeatures.h at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

is bit 0

OpenCorePkg/Include/Apple/IndustryStandard/AppleFeatures.h at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

is bit 1
and so on
You can flip the bits in the calculator (in essence this is HEX summation) and it will give you the HEX value, which you have to byte swap before entering in the configuration.

 

[joevt]

Can anyone help with a breakdown of the features contained in the suggested FirmwareFeatures (A1QM4A==) and FirmwareFeaturesMask (P/8f/w==)?

I can see a list of items in the OpenCore Source but trying to know what is on of off in those values that are going in.

Any hints ... @cdf ?

I only know what is listed at https://github.com/acidanthera/Open...nclude/Apple/IndustryStandard/AppleFeatures.h

It seems that the hex values are little endian? They can be made big endian and converted to binary:

# FirmwareFeatures
hex=$(echo -n "A1QM4A==" | base64 -D | xxd -u -g 4 -e | sed -E 's/^.+: //;s/ .*//;')
echo 0x$hex
echo "obase=2;ibase=16;$hex"|bc

# FirmwareFeaturesMask
hex=$(echo -n "P/8f/w==" | base64 -D | xxd -u -g 4 -e | sed -E 's/^.+: //;s/ .*//;')
echo 0x$hex
echo "obase=2;ibase=16;$hex"|bc

Result:

0xE00C5403
11100000000011000101010000000011
0xFF1FFF3F
11111111000111111111111100111111

Make sure all the 1 bits correspond to a feature flag, otherwise may need to not change endianness.

edited: use -D instead of -d with base64 for compatibility with older macOS.

 

[Dayo]

If I am reading the docs correctly, the FirmwareFeaturesMask covers the Extended Features:

Does this then mean the value is saying the cMP is using soldered memory?

OpenCorePkg/Include/Apple/IndustryStandard/AppleFeatures.h at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

I suppose I am not reading the docs correctly or is the spoofed IMacPro RAM soldered?

Hmm ... maybe this covers 64bits with zeros in the top part. Lost!

 

[startergo]

@cdf not sure how the FirmwareFeaturesMask is calculated. Any idea?

 

[Dayo]

hex=$(echo -n "A1QM4A==" | base64 -d | xxd -u -g 4 -e | sed -E 's/^.+: //;s/ .*//;')
hex=$(echo -n "P/8f/w==" | base64 -d | xxd -u -g 4 -e | sed -E 's/^.+: //;s/ .*//;')

"base64 -D" works. "base64 -d" throws an error

 

[startergo]

If I am reading the docs correctly, the FirmwareFeaturesMask covers the Extended Features:

View attachment 1683328
Does this then mean the value is saying the cMP is using soldered memory?

OpenCorePkg/Include/Apple/IndustryStandard/AppleFeatures.h at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

I suppose I am not reading the docs correctly or is the spoofed IMacPro RAM soldered?

Hmm ... maybe this covers 64bits with zeros in the top part. Lost!

You have to enable the extended features.

OpenCorePkg/Include/Apple/IndustryStandard/AppleFeatures.h at master · acidanthera/OpenCorePkg

OpenCore bootloader. Contribute to acidanthera/OpenCorePkg development by creating an account on GitHub.

github.com

Platform features are a different parameter.

 

[Dayo]

Yes you have to enable the platform features in the lower bits and then you can use platform features (bits 32-64).

Looks so. Strange that they would call it a mask instead of "ExtendedFirmwareFeatures"

From a quick search, it seems the RAM on the IMacPro is not considered user replaceable although apparently possible.
So I suppose it might as well be considered soldered.