hypervisor=: Enable special features in the Virtualization Stack (namely VM quota override).kcsuffix=: Set Kernel Collection variant to boot.Configure our Mac to boot our custom Kernel Collection (adjust Macintosh HD to your volume).Here we’ll set some policies for our machine: Next, authorize the user, and select Utilities -> Terminal from the Menubar. Use macOS Recovery on a Mac with Apple silicon.Configuring our Mac to boot the Development Kernel Collectionįinally shutdown your Mac, and boot into recovery by holding the power button and selecting “Option”: Keep in mind the path, as we’ll need to access this from recoveryOS. This will create a VirtualMachine.kc file in your home directory. #define CSR_ALLOW_APPLE_INTERNAL (1 << 4) For a bit more info on SIP, I wrote about that here: System Integrity Protection: The misunderstood setting.Instead, Apple swapped the hypervisor boot-arg with an AppleInternal check through System Integrity Protection: However, after some more research, I found that this logic is not the same in the release kernels. The former is a simple gate check for the latter, which is far more interesting: hv_apple_isa_vm_quota= can override the VM limitation in the kernel! Here we see how Apple handles the VM limitation: Using the int hv_apple_isa_vm_quota variable, the kernel decrements/increments the variable as new Virtual Machines as started/stopped: Increment FunctionĪnd something else is interesting, 2 new boot-args: hypervisor= and hv_apple_isa_vm_quota=. To get a development kernel, you’ll need to download your OS’ Kernel Debug Kit off the developer portal.Throwing the development kernel for macOS Sonoma Beta 4 (23A5301h) in IDA, I found the init code for the VM stack: hv_init(): So with a not-so-quick comparison between the functions and strings of the Intel and Apple Silicon kernels, I found that the main VM stack is under hv_vm_*. While I didn’t have any strings to go off of, I did know that the Intel Kernel won’t have the same code. At best, I could only determine that the error message was generated from the framework but nowhere in userspace itself does Apple define a hardcoded 2 VM limit…Īfter a tip from jevinskie on the Hack Different Discord server, I learned that Apple’s guest limitation is implemented somewhere within the closed-source part of XNU (the macOS kernel). However, after many hours of research, I was unable to find where Apple imposed the VM limit. With this, I was able to examine the framework more closely. More information on macOS Frameworks and the dyld shared cache: Battle against on-disk binaries. Due to macOS Big Sur’s dyld merger of frameworks, we’ll need to either extract the framework manually or use tooling such as Hopper Disassembler to load specific binaries embedded in the dyld shared cache. To start, I initially thought this limitation was userspace based and as such would be embedded somewhere within /System/Library/Frameworks/amework. While I cannot officially virtualize more than 2 copies of macOS on a single machine at once for work, I was still interested in figuring out where in macOS Apple embeds these checks and whether hobbyists and researchers could enable support for more than 2 active macOS VMs at once. (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |