My NVMe driver works fine in macOS 10.15, but in macOS 11.0, it won't be loaded when the system boots up.
I knew my driver is installed to auxiliary kext collection.
when the macOS11 boot, the system always load applenvme driver in Boot Kernel Collection.
How to make the system load my kext instead of applenvme kext at startup?
Unfortunately, it is not possible to "win" IOKit matching against Apple's own kexts during early boot with macOS 11. The auxiliary collection is not considered for matching during that early phase, and by the time the system has progressed far enough to load auxiliary kexts, the Apple kext is already driving the device.
I recommend filing a bug with Apple about this behaviour.
Related
I have a DriverKit extension that can match a usb audio device just fine, but if I leave the device plugged in during a reboot, the AppleUSBAudio kernel extension matches it instead.
Unplugging and replugging load my dext instead.
Is this to be expected? Do all System Extensions have this shortcoming? How can I remedy this?
On macOS 11, if one of Apple's kexts matches your device, and their driver is in the "boot" or "sys" collections (see man kmutil), which it normally will be, then their driver will win matching against yours, even if yours has a higher probe score.
On macOS 10.15, it should depend on whether or not their kext is in the prelinked kernel/kext cache. Third party kexts can also be included here so it's a little more democratic at least. Dexts can't be in the kextcache though.
I've filed an Apple DTS TSI about this issue and they've acknowledged it as a bug. I strongly recommend you file it as a bug as well to increase chances of it being fixed.
You should be able to work around it in a rather ugly way by explicitly force resetting the device from a user space daemon if your driver didn't manage to grab it. This will cause it to be re-enumerated by the USB subsystem, and for I/O Kit matching to be repeated, at which point your dext hopefully manages to win!
I had developed a kernel extension(kext) by IOKit, but it will be deprecated in the future. So I want develope another driver use dext to replace kext using the DriverKit. But I don't find the executable solutions, like that I cannot find the some class to repalce IOMedia. When I intend to include IOKit in my code,I found the TARGET_OS_DRIVERKIT is 1.
Can someone help me? Thanks a lot!
IOMedia is a subclass of IOStorage and part of the IOStorageFamily. As of the macOS 11.2 SDK (Xcode 12.4) this has not yet been ported to DriverKit.
The SCSIControllerDriverKit API has been in beta since WWDC 2020. It didn't ship with the release versions of macOS 11.0.x-11.2. It's included in the (as of this writing) current betas of 11.3. Perhaps it will see general release with macOS 11.3. This is not a direct port of the storage stack; instead, it's essentially a port of the IOParallelSCSIController KPI. This lets you implement a driver for, well, a SCSI controller. Such a driver can tell the OS about one or more SCSI devices, including block devices, and will start receiving SCSI commands from the system, which it is expected to forward to the underlying controller device. It does not allow you to implement "filter" storage drivers, or to issue SCSI commands to other devices in the system.
My kext file should be loaded automatically at mac os boot time.
It currently appears in / Library / Extention, but it does not seem to be loaded automatically at boot time.
Is there a way?
For it to load automatically, it must either be an IOKit based kext, or another kext that gets loaded must depend on it.
If it's an IOKit kext, and there is no specific device which should trigger the loading of the kext, you can simply match the IOResources object. The official documentation on device & driver matching talks about how to set up matching in general, and about matching IOResources specifically.
I am very new to Hackintosh and now I am studying the boot process.
As far as I know:
efi binary is a "byte-code" that UEFI firmware runs
kexts is the kernel mode device driver that is complied in machine specific code, loaded by the kernel, running in kernel mode with the kernel
kexts injection is like the dynamic loading of library but in kernel mode
My question is, why there is some relationship with the bootloader like chameleon/clover and the kexts? The kexts should be loaded by the kernel but not the bootloader, right?
I see thing here.
http://cloverboot.weebly.com/kexts.html?bcsi_scan_50b5cc4d2c82cc03=bG/X91Fwptz2CvnL0WdFPvjdTdWsAAAAioMalg==&bcsi_scan_filename=kexts.html
Say Hackintosh needs FakeSMC.kext. But it is not the business of the bootloader. What bootloader needs to do is to put the init code of Mac OS kernel in memory and passes the control to it. And it should be that Mac OS kernel loads that FakeSMC.kext.
Isn't it?
Firstly PCs in the past only had legacy bios and no EFI, but Apple never used legacy bios, only EFI.
But this has changed as now most of the modern PCs have builtin UEFI so there is no need to emulate EFI.
There are two ways to boot OS X on a hackintosh with legacy bios. The first is Chameleon and the second is Clover.
Clover and Chameleon loads OS X differently.
Clover uses a modified version of DUET EFI (open source EFI implementation on top of legacy bios) or if the computer has it's own UEFI built in clover uses that. Clover also uses the default bootloader on the OS X Partition located at /System/Library/CoreServices/boot.efi to boot OS X. boot.efi loads the kexts and passes control to the kernel as on a real mac.
Chameleon has it's own built in fake EFI implementation that makes the kernel think it's running on an EFI Mac. But that fake EFI is not enough to load boot.efi so Chameleon has it's own loader. Chameleon loads the kexts by itself and then passes the control over to the kernel.
Both bootloaders have built in ACPI table injection, SMBIOS spoofing, Device ID injection, etc.
FakeSMC is an emulator that emulates the System Management Controller found in a real Mac which contains the key to decrypt Apple Protected Binaries.
Chameleon loads FakeSMC and other kexts by itself as standalone or part of the kernelcache and if you use Clover the same thing gets done by boot.efi.
Note:
Clover has a feature that you're probably talking about that injects kexts on the fly that make it seem like they get loaded by Clover but they actually become part of the kernelcache.
My Application wants to access a HID device I plugged in, but claiming the device does not
work because its already claimed by IOHIDDevice Driver.
In order to prevent that I learned, that I should create and install a codeless kext driver
for mac(OSX 10.8.2) to blackbox my device from beeing loaded.
I spent two days already and I did not have any success so far.
In my testcase you can find
Log from the USB prober
My codeless kext module
output from ioreg when my device is attached
It seems i cannot attach a file here.
please download it from http://www.guenther-sohler.net/testcase.tar.gz
Depending on what level of access you require, HIDAPI http://www.signal11.us/oss/hidapi/ may provide you with what you need. It's a library that uses IOHidManager as a backend on OSX. Works for me on OSX 10.7.5, no dummy driver required.
Check into a code less KEXT to declare your device as available to user space apps.
It is essentially a plist.
For Yosemite and Mavericks, it needs to be signed by an Apple Developer ID approved for KEXT - you need to be a Developer and apply for that.