Debugging macOS Kernel Using VirtualBox
klue.github.io
klue.github.io
VMware's virtualization software (ESXi, Workstation, Fusion) has the concept of "CPUID masks", which can be used to mask off features to the guest from the host's CPU for this kind of work. Since it is a very advanced concept, we didn't expose it in the UI for Workstation or Fusion, but the VMX shipped with both products should support it as far as I know (I don't think we've ever disabled that feature for a product anyhow). If you dig into the menus you can set the flag values on ESXi, as sometimes for fleets we have admins that want to normalize their CPU flags across all of their virtual hardware (I believe this was very popular when the NX-bit was new).
However, you're not at a lost for the desktop products. Editing the [vm-name].vmx file and adding the lines to control the cpuid registers is a pretty simple endeavor; the lines are formatted 'cpuid.<cpuid-in>.<GPR> = "value"', and value should contain the mask for the whole 32-bit register, with a dash '-' for no special processing of this flag, "h" for using the host's setting of this flag, '0' for explicit disabling the flag, or '1' for explicit enabling the flag. For example:
cpuid.7.ebx = "--------------------0-----------"
(The VMX file is a bit non-obvious to get to on macOS, as we use 'packages' to make VMs nicer to handle, but simply right clicking the package and selecting "show package contents" should reveal the VMX file.)
[takes off VMware hat].
I'm pretty sure both VirtualBox and VMWare could create a Apple-friendly template with these settings already tweaked for what OSX expects. In fact it would be trivial.
But for some reason they haven't.
Considering how VMWare Workstation Pro actually supports running MacOS on Windows, but has the relevant config removed in production-builds (needing it to be hacked back in), I'm going to assume there's some kind of political pressure going on here. Maybe even from a certain Cupertino-based company, wanting to prevent the mainline virtualization providers from commodotizing their commodity, run of the mill, standard X86 PC operating system.
That's a shame, because if they didn't, it would certainly make it much easier for me to build a solid and reliable CI pipeline for our MacOS and iOS stuff.
cpuid.7.ebx = "-----------0--------------------"
machdep.cpu.leaf7_features: SMEP ERMS RDWRFSGS TSC_THREAD_OFFSET BMI1 HLE AVX2 BMI2 INVPCID RTM RDSEED ADX FPU_CSDS
[0] http://www.newosxbook.com/index.php?page=book
[1] https://developer.apple.com/library/content/documentation/Da...
Amit Singh has a Mac OS X Internals A Systems Approach that is good we well.
There are also various talks at security conferences that detail parts of macOS/iOS.
(iii) to install, use and run up to two (2) additional copies or instances of the Apple Software within virtual operating system environments on each Mac Computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
Apple allows 3rd party kernel extensions so naturally you would need to be able to debug the kernel. In my post, I link plenty of official Apple documentation that provide information on how to debug the kernel.
Also, I was careful to not say legal/illegal but allowed/disallowed. I am pretty sure that macOS disables some debugging calls, or at least it used to. What are the limits?
- An old call, ptrace(PT_DENY_ATTACH), which prevents the process that calls it from being debugged (with either ptrace or dtrace). iTunes calls this. It's always been rather easy to circumvent, either by attaching before the process has the chance to make the call, or by installing a kext that disables the functionality.
- System Integrity Protection broadly prohibits debugging of system processes, as well as kernel tracing via dtrace. But SIP can be disabled by the user, by design.
Kernel debugging in particular is explicitly supported by Apple in the form of Kernel Debug Kits, which consist of debug symbols for the open source parts of the kernel, as well as variant builds with more debugging stuff enabled at compile time. Peeking at the proprietary parts is presumably against the license agreement but not technically restricted in any way (hard to imagine what such a restriction would look like).
If it's illegal, it's up to Apple to deal with it. Why go out of the way doing free work for them?
I haven't completely read it (if only because it is 424 pages in multiple languages), but http://images.apple.com/legal/sla/docs/macOS1012.pdf does state:
"M. No Reverse Engineering. You may not, and you agree not to or enable others to, copy (except as expressly permitted by this License or by the Usage Rules if they are applicable to you), decompile, reverse engineer, disassemble, attempt to derive the source code of, decrypt, modify, or create derivative works of the Apple Software or any services provided by the Apple Software or any part thereof (except as and only to the extent any foregoing restriction is prohibited by applicable law or by licensing terms governing use of Open-Sourced Components that may be included with the Apple Software)."
I am not a lawyer, so I don't dare guess at what it really means, but I would guess there are many jurisdictions where most of that doesn't have any implication for persons _buying_ a Mac (a license requires an agreement between parties and cannot be something that one party forces upon another party)
Also, many licenses of open source parts do allow you to do anything with the software, including reverse engineering. I expect that means you are free to debug, say, the Mac OS kernel, once its source has been open sourced.
Source: maintainer of https://github.com/geerlingguy/macos-virtualbox-vm
Instead, Server.app does two things:
1. similar to Xcode, Server.app ships with a POSIX env inside it (nothing chroot/jail-y going on; it just has programs ./configure'd with that env as their --prefix, and some stub programs in the base system that exec their /Applications/Server.app equivalents if they exist);
2. it updates [non-rootless-protected] configuration files, that activate previously-inactive parts of the base system, like opendirectoryd and racoon.
AIUI their profits really come from the hardware sales, so if people try macOS and eventually decide to buy a Mac, Apple wins; if they don't, then Apple didn't really lose either, because those people wouldn't ever buy a Mac anyway.
I played around with Hackintoshing and even writing/porting device drivers to get my install working, and that was somewhat fun, and I even tried out some of the other interesting Mac-only software(z), but in the end I still preferred to use Windows and Linux.
Is it allowed?
Really it is on Apple to attempt to prevent this. Not on the hacker. There isn't many ways an OS vendor and prevent their product from being virtualized. If Apple was smart they'd maybe clean up OSX to have a decent cloud offering.
But alias nope.
Fwiw the same is true if you could virtualize iOS.
And there are plenty of use cases:
* an iOS development offering (as long as iOS development is restricted to Mac OS X)
* security research
* integration with software not available on Linux (e.g. something Photoshoppy)
* hardcore fanboys who can't stomach using anything not ordained by Apple
It's attractive because I can rent it when I need it, versus buying a Mac (or copy of OSX) I'll only use occasionally.
There is 100% method to freeze system while communicating with external monitor using iokit framework over I2C. https://apple.stackexchange.com/questions/61045/does-apple-s...
Sometimes there are too many errors to deal with. I find building on a machine that's on the exact macOS version that you are trying to build does the trick.
gIOScreenLockState