7 replies to this topic

[solarein]

From what I understand, the OS X installer checks the system identification to see if the machine it is running on is a compatible Apple-made computer before it proceeds, which is why hackintosh bootloaders inject Mac identifiers in order to allow the OS X installer to run. However, I'm not sure about other hypervisors, but virtual machines on VMware products do not identify themselves as Apple products to OS X. Instead they identify as VMware7,1 and the like. Does anyone know why the OS X installer nonetheless proceeds on these VMs? Is OS X hardcoded to accept certain VMware-identified machines the same way it accepts certain Apple machines? Or does OS X have a more general way to identify whether it is being installed on a virtual machine and proceeds in such cases?

Also, does anyone know if the machine identification check is only done during install time, or is it also done on each boot of the system as well?

[MSoK]

solarein, on 13 December 2012 - 01:37 PM, said:

From what I understand, the OS X installer checks the system identification to see if the machine it is running on is a compatible Apple-made computer before it proceeds, which is why hackintosh bootloaders inject Mac identifiers in order to allow the OS X installer to run. However, I'm not sure about other hypervisors, but virtual machines on VMware products do not identify themselves as Apple products to OS X. Instead they identify as VMware7,1 and the like. Does anyone know why the OS X installer nonetheless proceeds on these VMs? Is OS X hardcoded to accept certain VMware-identified machines the same way it accepts certain Apple machines? Or does OS X have a more general way to identify whether it is being installed on a virtual machine and proceeds in such cases?

Also, does anyone know if the machine identification check is only done during install time, or is it also done on each boot of the system as well?

I am not the expert in this area, but here goes. OS X installations expect to see an Apple System Management Controller (SMC) with relevant identifier before they will proceed hence the SMC injection required for Hackintosh PC's. In VMware OS X installations are allowed based on Apple's EULA on Apple hardware, i.e. VMware Fusion running under OS X and ESXi on Xserve, Mac Pro and although not on the HCL the Mac Mini. If VMware ESXi detects non Apple hardware the functionality to install OS X is disabled or probably more accurately hidden.

Interestingly the latest 2012 Mac Mini's SMC has changed sufficiently for VMware's AppleSMC VMkernel driver not to recognise the Mac Mini as Apple hardware, requiring an unofficial VMware engineering patch to allow OS X to be installed on a 2012 Mac Mini running ESXi 5.1, or use Donk and Zenith's "Unlocker" as we do for ESXi, Workstation or Player installed on non Apple hardware.

So in conclusion, an OS X installation interrogates the hardware and if it does not see an AppleSMC will not install. VMware emulate this with their AppleSMC VMkernel driver allowing OS X to be installed, however VMware carry out the hardware interrogation at the ESXi level and "hide" the functionality if the hardware does not meet Apple's EULA. The "Unlocker" in effect "un-hides" the Apple options allowing OS X to be installed on non Apple hardware under VMware ESXi, Workstation and Player.

Finally, the check is done at every boot, as if you upgrade or patch ESXi, Workstation or player without re-applying the "Unlocker" OS X will not boot on non Apple hardware.

I hope I have partially answered your questions, and my response is not to technically inaccurate, MSoK.

[solarein]

Thank you for the very detailed instruction. I didn't know about the role the SMC played in the system interrogation process. That was very helpful.

My next question would be, what values does OS X expect to retrieve from the SMC in order to proceed? I originally thought this would be something as simple as the manufacturer string identifying as "Apple", but VMware's SMC emulation seems to identify the machine as made by VMware with a VMware specific model name. Is the system using something more subtle in order to identify Apple-made hardware and approved hypervisors?

[Zenith432]

solarein, on 13 December 2012 - 01:37 PM, said:

From what I understand, the OS X installer checks the system identification to see if the machine it is running on is a compatible Apple-made computer before it proceeds, which is why hackintosh bootloaders inject Mac identifiers in order to allow the OS X installer to run. However, I'm not sure about other hypervisors, but virtual machines on VMware products do not identify themselves as Apple products to OS X. Instead they identify as VMware7,1 and the like. Does anyone know why the OS X installer nonetheless proceeds on these VMs? Is OS X hardcoded to accept certain VMware-identified machines the same way it accepts certain Apple machines? Or does OS X have a more general way to identify whether it is being installed on a virtual machine and proceeds in such cases?

This is done by a script in OSInstall.mpkg on InstallESD.dmg.  It checks if it's running in a virtual machine and lets it continue - skipping the ID check.  You can unpack the script with 'pkgutil --expand' and see exactly what the code does.

[solarein]

Zenith432, on 14 December 2012 - 11:18 AM, said:

This is done by a script in OSInstall.mpkg on InstallESD.dmg.  It checks if it's running in a virtual machine and lets it continue - skipping the ID check.  You can unpack the script with 'pkgutil --expand' and see exactly what the code does.

Interesting. The "VMM" feature doesn't seem to be a feature that CPUID actually returns. Is this a bogus feature that sysctl tacks onto the end of the real feature list so that other utilities can use it to detect if it's running inside a virtual machine? If so, I guess that means the real virtual machine detection logic is hidden in sysctl somewhere.

[Zenith432]

solarein, on 15 December 2012 - 06:06 PM, said:

Interesting. The "VMM" feature doesn't seem to be a feature that CPUID actually returns. Is this a bogus feature that sysctl tacks onto the end of the real feature list so that other utilities can use it to detect if it's running inside a virtual machine? If so, I guess that means the real virtual machine detection logic is hidden in sysctl somewhere.

sysctl is a user-mode interface for retrieving kernel parameters.  For feature settings in the kernel see cpuid.h and cpuid.c here.

[solarein]

Zenith432, on 15 December 2012 - 07:27 PM, said:

sysctl is a user-mode interface for retrieving kernel parameters.  For feature settings in the kernel see cpuid.h and cpuid.c here.

I'm aware. But the script in OSInstall.mpkg is calling sysctl, which is then I assume using the CPUID instruction to retrieve the list of CPU features. That's why I think sysctl is tacking VMM to the end of the list of features it retrieves when it detects it's running on a virtual machine, since that feature isn't one that CPUID returns.

[Zenith432]

solarein, on 15 December 2012 - 07:51 PM, said:

I'm aware. But the script in OSInstall.mpkg is calling sysctl, which is then I assume using the CPUID instruction to retrieve the list of CPU features.

No, it's not.  The CPU feature detection is done once during boot in the kernel and stored in always-resident data structures.  sysctl can be called at any time to retrieve info from the kernel.  The list of CPU features detected by the kernel (including VMM) is in cpuid.h, and the code to do it is cpuid.c.