On macOS, what is a kernel extension (kext), and why has Apple pushed third-party drivers out of the kernel into System Extensions and DriverKit?

## What a kext is A **kernel extension** is a loadable bundle of code that becomes part of the running XNU kernel. Historically kexts covered three things: device drivers, filesystems, and network/security filters. Once loaded, kext code runs at kernel privilege in the kernel's address space with no memory protection separating it from anything else in the kernel. Most kexts are **IOKit** drivers. IOKit is an object-oriented driver framework written in a restricted C++ dialect provided by `libkern`: driver classes derive from `OSObject` and `IOService`, and the runtime uses `OSMetaClass` for type information because the usual C++ features that a kernel cannot afford — exceptions, RTTI, multiple inheritance — are unavailable. A driver implements the service lifecycle, principally `probe`, `start` and `stop`. ## Matching: data, not code The part that surprises engineers coming from Linux is how a driver is bound to hardware. There is no `modprobe` alias table and no `udev` rule. Each kext declares **personalities** in its `Info.plist` under `IOKitPersonalities`, naming an `IOProviderClass` (the kind of parent object it attaches to), an `IOClass` (the C++ class to instantiate) and matching keys for the device. When XNU discovers hardware it publishes a nub in the **I/O Registry**, scores all candidate personalities, and starts the best match. You can inspect that live tree with `ioreg`. Driver matching is therefore declarative data, evaluated at runtime. ## Why the kernel is a bad place for third-party code The case against kexts is straightforward and worth stating in the interview as consequences, not adjectives: - **Reliability.** A bug that would be a segfault in a userspace process is a **kernel panic**. One vendor's driver takes the whole machine down, mid-flight, with unsaved work. - **Security.** A kext runs with the highest privilege in the system. A vulnerability in it is a full system compromise, and it is a natural target for attackers who cannot beat the platform's own defences. - **Compatibility.** Kexts link against kernel-internal symbols that Apple is free to change. Every OS update risks breaking them, which historically blocked users from upgrading. - **Architecture churn.** In-kernel code must be native for the CPU; there is no compatibility translation layer inside the kernel. ## The replacement: System Extensions and DriverKit From macOS 10.15 Apple deprecated third-party kexts and shipped **System Extensions**: bundles delivered inside an application that run as **userspace** processes but occupy the roles kexts used to. - **DriverKit** extensions ("dexts") implement device drivers using an API deliberately shaped like IOKit — familiar class names and lifecycle — but executing outside the kernel with a restricted set of entitlements. - **Endpoint Security** replaces in-kernel security/monitoring filters for EDR and anti-malware products. - **Network Extension** replaces in-kernel network filters, content filters and VPN plugins. The engineering payoff: a crash is a process crash, and the extension can be restarted rather than panicking the host; a compromise is contained by the process boundary and the extension's entitlements; and the API is a supported contract instead of kernel-internal symbols. The cost, which an honest answer should acknowledge: DriverKit exposes a subset of what the kernel could do, so some device classes still cannot be expressed; there is a cross-boundary cost for very high-throughput or latency-critical hardware; and each extension type requires an entitlement granted by Apple, so the vendor's ability to ship is gated on the platform owner. ## Where kexts stand today Since macOS 11 the kernel and its bundled extensions are prelinked into **kernel collections** — a boot collection built at install/update time, with auxiliary collections for approved third-party kexts — managed by `kmutil`. The older per-load tools are deprecated. Loading a third-party kext now requires explicit user approval, and on Apple Silicon it additionally requires lowering the machine's startup security level and rebooting, which for a fleet means touching every device. That operational friction is itself the point: Apple made the in-kernel path expensive so vendors migrate. ```bash kmutil showloaded # kexts currently in the kernel systemextensionsctl list # userspace system extensions installed ``` ## How to answer well Define a kext in one sentence, name IOKit and the `Info.plist` matching model to show you know what one actually contains, then give the reliability/security argument in terms of a panic versus a restartable process. Finish with the honest tradeoff — reduced capability and Apple-gated entitlements — rather than presenting the migration as pure upside.