11.1. THE KERNEL ENVIRONMENT

The conditions that exist inside the kernel are more similar to those encountered by a Mac OS 9 application than to those encountered by a user-level application on Mac OS X. Many of the protections that separate Cocoa applications from each other and from system processes do not exist for kernel extensions, meaning that you have to be much more defensive in your development practices. While it is rare to encounter a malicious KEXT (though the kernel would certainly be a good place for a root kit — code that hides malware from the user — to dwell), poorly programmed KEXTs are likely to interfere with each other or the correct operation of the kernel. Any such interference is very likely to lead to a loss of stability or availability of the entire operating system: the dreaded kernel panic.

The main problem you will encounter in developing your KEXT is a lack of memory protection. At the user level, each application has its own memory allocation, which is reserved by the kernel and inaccessible to other processes. Any application is responsible for any reading or writing in its allocated memory, and while that doesn't entirely preclude memory access problems, it does reduce the attack surface to issues introduced by the process owning the memory. In contrast, any code running in the kernel's memory space (the code in Apple's kernel, xnu, itself, and all loaded KEXTs) has the same permission to all memory. A buffer overflow in your KEXT could end up writing into memory in another KEXT or the kernel, causing a change in behavior, a kernel panic, or even execution of code introduced by an attacker. Code running in the kernel has unfettered access to the computer's resources, with even more permission than the root user. If your KEXT permits attackers to introduce their own programs to the kernel, you really do give up the keys to the kingdom.