Kernel Extension Installation in OSX10.11

Hello --


We have a Kernel Extension (.kext) that is currently installed to /Library/Extensions/ on Mavericks and Yosemite. On the 10.11 beta however, this fails. The .kext folder is created by our installer/update utility, and the permissions & ownership seem to be correct, but it will not load.


What has changed here?


I should also add: Manually installing to /System/Library/Extensions seems to work. It's my understanding that this is a reserved (hence the "System" part) area for Apple extensions, however.


Thanks for any help!

Replies

How are you trying to load it?

Do you see anything in the system log?

What does

kextutil
say? See the "Diagnosing Kexts" section of the man page.

Share and Enjoy

Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Also, is the kext properly signed?

Eskimo & POM, thanks for your responses --


Yes, the driver is correctly signed (unless something in this process I don't know about has changed since Yosemite). Messing around with kextutil got a working away of loading the module, but I'm not sure why the way we've been doing it is failing:


Previously (from a daemon running as root): "/sbin/kextload -b com.contentwatch.ghoti.NARCPacketInterceptor"


Manually running this on El Capitan results in the following error:

com.contentwatch.ghoti.NARCPacketInterceptor failed to load - (libkern/kext) not found; check the system/kernel logs for errors or try kextutil(8).


(System log says essentailly the same thing: It cannot find com.contentwatch.ghoti.NARCPacketInterceptor)


However, both kextutil and kextload using the path of /Library/Extensions/NARCPacketInterceptor.kext work. The output of kextstat with the module loaded shows the identifier that was being used with -b above:

107 0 0xffffff7f821f3000 0x9000 0x9000 com.contentwatch.ghoti.NARCPacketInterceptor (1) 975B6261-0A61-3DFE-BCB7-D25BB429332E <4 1>


Are we going to have to move to using the path? Is this expected?

Can you post what you got from "kextutil -nt /Library/Extensions/NARCPacketInterceptor.kext"?

/Library/Extensions/NARCPacketInterceptor.kext appears to be loadable (including linkage for on-disk libraries).

Sorry to "bump" this, but any ideas on this? Should we fall back to using kextload with a absolute path? Should -b still be working? We would like to have a fix in before the official release and I'd like to avoid using the path if that's not the appropriate fix.

One last "bump" on this. Any ideas on any of the above?


The current work around seems to be to to use the full path when loading. We need to get a release wrapped up and ready for El Capitan, so this is what I'll go with unless advised otherwise.


Thanks!

I've got a small shot in the dark. There are a couple of kext management functions in IOKit. You could try using those functions to load and unload by identifier in your daemon or in a little test utility. These should behave just like kextload kextunload (kextutil), but it might be worth an experiment.