The last family — actual hardware drivers — and the in-kernel world they replaced. Why your Mac runs 256 kexts and not one of them is third-party.
.dext) differs from a legacy IOKit kext, see the live kext list on your own Mac, and understand the Apple-Silicon gauntlet a real kext must pass — closing the loop from Lesson 1.com.apple.*)A DriverKit driver is the fourth System Extension family. It uses the same object model as the old in-kernel IOKit — you subclass IOService, match against hardware, drive registers — but it runs as a sandboxed user-space .dext ("driver extension"). A crash kills the driver, not the Mac.
| Subframework | For |
|---|---|
USBDriverKit | USB devices |
HIDDriverKit | keyboards, mice, game controllers |
PCIDriverKit | PCIe cards |
SerialDriverKit / NetworkingDriverKit / AudioDriverKit | serial, NICs, audio interfaces |
It's C++ (a restricted dialect), and the entitlement (com.apple.developer.driverkit) is Apple-granted via the request form — like Endpoint Security, not self-service. So we cover it, but don't build it (you'd also want real hardware to drive).
Before DriverKit, every driver was a kext running inside the kernel. Look at what's loaded on your Mac — and notice who signed all of it:
And a real IOKit driver object, live in the I/O Registry on your machine:
AppleT8132USBXHCI is the USB-controller driver for your M-series chip — an IOKit class, matched to hardware, sitting in the kernel. The ioreg tree is that whole live graph of driver objects.
It's not luck — it's policy. Apple has been deleting the KPIs kexts depend on, version by version, and steering everything to the user-space families you've spent this course on:
If you did need a genuine third-party kext, here's the price — the friction you avoided by building a System Extension instead:
| Gate | What it means |
|---|---|
| Reduced Security | Set in 1TR (hold power at boot). Even a signed third-party kext needs the boot policy dropped below Full Security + "allow kernel extensions" toggled. |
| Permissive Security | csrutil disable (SIP off) for unsigned self-built kexts. |
| AuxKC | Approved kexts are compiled into the Auxiliary Kernel Collection, which loads after the sealed Boot/System collections — so every kext change needs a reboot. |
| kmutil | The modern tool: kmutil load -p <path>, kmutil showloaded. (kextload/kextstat still work but shim to it.) |
Your content filter: ./build.sh → provision → approve → running, SIP on, no reboot. A kext: recovery reboots, lowered security, AuxKC rebuild, another reboot. That is why Apple built System Extensions — and why you reframed the mission toward them.
| kext (legacy) | DriverKit dext | NE / ES sysext | |
|---|---|---|---|
| Runs in | kernel | user space | user space |
| Crash = | kernel panic | dead process | dead process |
| Language | C / C++ | C++ | Swift / Obj-C (ES: C) |
| SIP | must lower | stays on | stays on |
| Reboot to change | yes (AuxKC) | no | no |
You set out to know the common extensions, the languages, how to build one from the ground up, and to run a CLI build and see it on your Mac. All four — done. The one remaining hands-on step is yours: provision and approve your filter from Lesson 5.
Both are drivers using the IOKit object model; a kext runs in the kernel (panic risk, SIP must lower, reboot to change), a DriverKit dext runs sandboxed in user space (SIP on, no reboot).
Third-party kexts live in the AuxKC, which is built and loaded at boot after the sealed kernel collections. Rebuilding it needs a restart.
kextstat | grep -v com.apple → only the header line; every loaded kext is Apple-signed.
Request form: Endpoint Security, DriverKit. Self-service: Network Extension, Camera (CMIO).