WHAT'S IN THIS CHAPTER?
The kernel's security environment
Vetoing filesystem access
Writing kernel extensions, or KEXTs, is a very different matter from building user applications. Your kernel extension code receives an unmatched level of access to the operating system's facilities, and a corresponding elevated level of care must be taken to stop that access from being abused.
Apple's kernel programming guide tells you to keep out of the kernel. This is a good warning, and I want to reinforce it here. Only ship a kernel extension if your product cannot be implemented without it. The restrictions and requirements on kernel code are entirely unlike those on a user application, and there are many pitfalls that can lead to systems becoming unresponsive with no chance for users to save their data.
For some scenarios in which you might consider developing a KEXT, there are alternatives that allow you to avoid it. If you want to implement a new filesystem, use the MacFUSE library, available at
http://code.google.com/p/macfuse/. MacFUSE implements a small, well-tested virtual filesystem KEXT that calls out to user-level applications to read and write data. You write an application that interacts with your filesystem and responds to callbacks from the KEXT — avoiding the need for you to deal directly with kernel development.
If you need to write a device driver, consider using the user-level library provided by Apple, IOKit.framework, to stay out of the kernel. ...