Page 1 of 1

Generic Kernel Extension vs IOKit Driver

PostPosted: Fri Jan 13, 2017 7:34 pm
by scknight
Is there some reference that helps explain when you would want to write a kext as a generic kernel extension vs an IOKit driver? Are there differences in how they're loaded that comes into play when making the decision? Is it based on the different ways user space interacts with the driver?

I noticed on macOS that Sandbox.kext is a generic kernel extension but AppleMobileFileIntegrity.kext is an IOKit driver. I've seen other things like Little Snitch that are also IOkit drivers but then seen other example kexts doing MAC policies just as a generic kernel extension.

I couldn't find any definite answer from Apple's kernel programming guide so I was hoping someone here might be able to shed some light on the subject for me.

Re: Generic Kernel Extension vs IOKit Driver

PostPosted: Sat Jan 14, 2017 2:36 am
by morpheus
You'd want an IOKit driver rather than a generic kext if:

- You want to inherit from an IOFamily so as to utilize generic family code (e.g. creating a network adapter and having all the boilerplate packet stuff done for you, or creating a USB device , etc)


- You want to use an IOUserClient interface (e.g. AMFI, that's why it's an IOKit driver)


- You want to expose one or more IOPersonalities which will define your load order, or preference based on an IORegistry object/property change/notification

Other that that, if you don't want inheritance, are purely virtual and are self contained (e.g. Sandbox), you can be a generic kext.

Re: Generic Kernel Extension vs IOKit Driver

PostPosted: Sat Jan 14, 2017 5:30 pm
by scknight
Thanks for the info. One follow up question. Is there an advantage to using an IOUserClient interface rather than something like the kern control apis?