{
	"id": "8fdfff41-c1b9-44c4-ae4d-3a28f4b757d4",
	"created_at": "2026-04-06T00:15:37.297773Z",
	"updated_at": "2026-04-10T13:11:55.880908Z",
	"deleted_at": null,
	"sha1_hash": "a5e78395ffbda7e6865c569525cd1b85f81af043",
	"title": "What Is the I/O Kit?",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 100890,
	"plain_text": "What Is the I/O Kit?\r\nPublished: 2014-04-09 · Archived: 2026-04-05 18:38:15 UTC\r\nThe I/O Kit is a collection of system frameworks, libraries, tools, and other resources for creating device drivers in\r\nOS X. It is based on an object-oriented programming model implemented in a restricted form of C++ that omits\r\nfeatures unsuitable for use within a multithreaded kernel. By modeling the hardware connected to an OS X system\r\nand abstracting common functionality for devices in particular categories, the I/O Kit streamlines the process of\r\ndevice-driver development.\r\nThis chapter talks about the inherent capabilities of the I/O Kit (and of the drivers developed with it), about the\r\ndecisions informing its design, and about the I/O Kit when considered as a product. It also offers some caveats and\r\nguidelines for those considering developing kernel software such as device drivers.\r\nBefore You Begin\r\nYou might have developed device drivers for other platforms—Mac OS 9, perhaps, or BSD or another flavor of\r\nUNIX. One thing you’ll discover reading this document is how different the approach is with the I/O Kit.\r\nAlthough writing drivers for OS X requires new ways of thinking and different ways of programming, you are\r\namply rewarded for shifting to this new approach. The I/O Kit simplifies driver development and supports many\r\ncategories of devices. Once you get the basics of the I/O Kit down, you’ll find it a relatively easy and efficient\r\nmatter to create device drivers.\r\nBefore you attempt driver development with the I/O Kit, Apple highly recommends certain prerequisites. Because\r\nthe framework uses an object-oriented programming model, which is implemented in a restricted subset of C++, it\r\nhelps to know C++ or object-oriented concepts in general. Also, device drivers are not the same thing as\r\napplications because, being kernel-resident, they must abide by more restrictive rules. Knowledge of kernel\r\nprogramming is therefore very useful.\r\nIndeed, programming in the kernel is discouraged except when it is absolutely necessary. Many alternatives for\r\ncommunicating with hardware and networks exist at higher levels of the system, including the “device interface”\r\nfeature of the I/O Kit described in Controlling Devices From Outside the Kernel See Should You Program in the\r\nKernel? for more on alternatives to kernel programming.\r\nI/O Kit Features\r\nFrom its inception, the fundamental goal for the I/O Kit has been to accommodate and augment native features\r\nand capabilities of OS X, particularly those of the kernel environment. As the driver model for OS X, the I/O Kit\r\nsupports the following features:\r\nDynamic and automatic device configuration (plug-and-play)\r\nMany new types of devices, including graphics acceleration and multimedia devices\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 1 of 10\n\nPower management (for example, “sleep” mode)\r\nThe kernel’s enforcement of protected memory—separate address spaces for kernel and user programs\r\nPreemptive multitasking\r\nSymmetric multiprocessing\r\nCommon abstractions shared between types of devices\r\nEnhanced development experience—new drivers should be easy to write\r\nThe I/O Kit supports these kernel features with its new model for device drivers and adds some additional\r\nfeatures:\r\nAn object-oriented framework implementing common behavior shared among all drivers and types\r\n(families) of drivers\r\nMany families for developers to build upon\r\nThreading, communication, and data-management primitives for dealing with issues related to\r\nmultiprocessing, task control, and I/O-transfers\r\nA robust, efficient match-and-load mechanism that scales well to all bus types\r\nThe I/O Registry, a database that tracks instantiated objects (such as driver instances) and provides\r\ninformation about them\r\nThe I/O Catalog, a database of all I/O Kit classes available on a system\r\nA set of device interfaces—plug-in mechanisms that allows applications and other software in “user space”\r\nto communicate with drivers\r\nExcellent overall performance\r\nSupport for arbitrarily complex layering of client and provider objects\r\nThe I/O Kit’s object-oriented programming model is implemented in a restricted subset of C++. Object-orientation\r\njust in itself is an advantage in driver development because of the code reusability it fosters. Once you are familiar\r\nwith the I/O Kit, you can write device drivers much more quickly and efficiently than you can using a procedural\r\nmodel. In addition, code reusability decreases the memory footprint of drivers; drivers ported from Mac OS 9, for\r\nexample, have been up to 75% smaller in OS X.\r\nDesign Principles of the I/O Kit\r\nOS X is largely the product of two strains of operating-system technology: Mac OS 9 (and its predecessors) and\r\nBSD. Given this pedigree, one might have expected Apple to adopt the device-driver model of Mac OS 9 or\r\nFreeBSD. Instead, Apple chose to redesign the model. Several reasons motivated this decision.\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 2 of 10\n\nFirst, neither the Mac OS 9 driver model nor the FreeBSD driver model offers a set of features rich enough to\r\nmeet the needs of OS X. The OS X kernel is significantly more advanced than its Mac OS precursors; it handles\r\nmemory protection, preemptive multitasking, multiprocessing, and other features not present in previous versions\r\nof Mac OS. Although FreeBSD is capable of handling these features, the BSD model does not offer other features\r\nexpected in a modern operating system, including automatic configuration, driver stacking, power management,\r\nand dynamic loading of devices.\r\nThus the primary motivation behind the I/O Kit was the inadequacy of the currently available driver models. The\r\nredesign of the I/O architecture had to take advantage of and support the operating-system features of OS X.\r\nToward this end, the I/O Kit’s designers settled on an object-oriented programming model that abstracted the\r\nkernel capabilities and hardware of an OS X system and provided a view of this abstraction to the upper layers of\r\nthe operating system. The compelling part of this abstraction is the implementation of behavior common to all\r\ndevice drivers (or types of device drivers) in the classes of the I/O Kit.\r\nAs an example, consider virtual memory. In Mac OS 9, virtual memory is not a fundamental part of the operating\r\nsystem; it is an option. Because of this, a developer must always take virtual memory into account when creating a\r\ndriver, and this raises certain complications. In contrast, virtual memory is an inherent capability of OS X and\r\ncannot be turned off. Because virtual memory is a fundamental and assumed capability, knowledge of it is\r\nincorporated into system software and driver writers do not have to take it into account.\r\nThe I/O Kit functions as a kind of foundation and coordinator for device drivers. This is a departure from previous\r\ndriver models. In Mac OS 9, all software development kits (SDKs) are independent of each other and duplicate\r\ncommon functionality. OS X delivers the I/O Kit as part of a single kernel development kit (KDK); all portions of\r\nthe KDK rest on common underpinnings. OS X helps developers take advantage of hardware complexity without\r\nrequiring them to encode software complexity into each new device driver. In most cases, they need only add the\r\nspecific code that makes their drivers different.\r\nAnother part of the design philosophy of the I/O Kit is to make the design completely open. Rather than hiding\r\nAPIs in an attempt to protect developers from themselves, all I/O Kit source code is available as part of Darwin.\r\nDevelopers can use the source code as an aid to designing (and debugging) new drivers.\r\nLimitations of the I/O Kit\r\nAlthough the I/O Kit supports most types of hardware on an OS X system, it does not fully support all hardware.\r\nOne category of such devices are those used for imaging, among them printers, scanners, and digital cameras. The\r\nI/O Kit provides only limited support for these devices, handling communication with these devices through the\r\nFireWire and USB families. Applications or other programs in user space are responsible for controlling the\r\nparticular characteristics of these devices (see Controlling Devices From Outside the Kernel for details). If your\r\napplication needs to drive an imaging device, you should use the appropriate imaging software development kit\r\n(SDK).\r\nAlthough the I/O Kit attempts to represent the hierarchy and dynamic relationships among hardware devices and\r\nservices in an OS X system, some things are difficult to abstract. It is in these gray areas of abstraction, such as\r\nwhen layering violations occur, that driver writers are more on their own. Even when the I/O Kit representation is\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 3 of 10\n\nclean and accurate, the reusability of I/O Kit family code can be limited. All hardware can have its own quirks and\r\na driver’s code must take these quirks into account.\r\nLanguage Choice\r\nApple considered several programming languages for the I/O Kit and chose a restricted subset of C++.\r\nC++ was chosen for several reasons. The C++ compiler is mature and the language provides support for system\r\nprogramming. In addition, there is already a large community of Macintosh (and BSD) developers with C++\r\nexperience.\r\nThe restricted subset disallows certain features of C++, including\r\nExceptions\r\nMultiple inheritance\r\nTemplates\r\nRuntime type information (RTTI)—the I/O Kit uses its own implementation of a runtime typing system\r\nThese features were dropped because they were deemed unsuitable for use within a multithreaded kernel. If you\r\nfeel you need these features, you should reconsider your design. You should be able to write any driver you\r\nrequire using I/O Kit with these restrictions in place.\r\nUsing Namespaces in an I/O Kit Driver\r\nNote that you can use namespaces in your I/O Kit driver. The use of namespaces can help you avoid name\r\ncollisions and may make your code easier to read and more maintainable. Be sure to use reverse-DNS format for\r\nthe namespace name (for example, com.mycompany ) to avoid potential namespace collisions.\r\nIf you decide to use namespaces in your in-kernel I/O Kit driver, do not declare any subclass of OSObject in a\r\nnamespace or your driver will not load. At present, the loader does not support OSObject-derived classes that\r\nrequire qualification, such as the one shown below:\r\nnamespace com.mycompany {\r\n class com.mycompany.driver.myClass : public IOService { // This is not allowed.\r\n OSDeclareDefaultStructors (com.mycompany.driver.myClass);\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 4 of 10\n\n};\r\n};\r\nUsing Static Constructors in an I/O Kit Driver\r\nIn OS X v10.4, GCC 4.0 is the default compiler for all new projects, including I/O Kit drivers. This section\r\ndescribes a particular difference between GCC 3.3 and GCC 4.0 that may affect the compatibility of your in-kernel driver between OS X v10.3.x and OS X v10.4.x. For more information on the differences between GCC 3.3\r\n(the default compiler in OS X v10.3) and GCC 4.0, including porting guidance, see GCC Porting Guide.\r\nIf you perform static construction within a function in a C++ I/O Kit driver (or other KEXT) compiled with GCC\r\n3.3 or earlier, be aware that the same KEXT compiled with GCC 4.0 will no longer load successfully. This is\r\nbecause GCC 4.0 is more strict about taking and releasing locks in the kernel environment. If you perform in-function static construction in your I/O Kit driver compiled with GCC 4.0, you will probably see the following\r\nerror when you try to load it:\r\nkld():Undefined symbols:\r\n__cxa_guard_acquire\r\n__cxa_guard_release\r\nThe solution to this problem is simple: move the static constructor to a global namespace. For example, suppose\r\nthat your I/O Kit driver includes an in-function static construction, such as in the code shown below:\r\nclass com_mycompany_driver_mystaticclass;\r\nvoid com_mycompany_driver_myclass::myfunction(void)\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 5 of 10\n\n{\r\n static com_mycompany_driver_mystaticclass staticclass;\r\n staticclass.anotherfunction();\r\n}\r\nYou can avoid loading errors by changing this code to avoid in-function static construction, as in the code shown\r\nbelow:\r\nclass com_mycompany_driver_mystaticclass;\r\nstatic com_mycompany_driver_mystaticclasss staticclass;\r\nvoid com_mycompany_driver_myclass::myfunction(void)\r\n{\r\n staticclass.anotherfunction();\r\n}\r\nNote that you may be able to avoid the load errors associated with in-function static construction without changing\r\nyour code if you compile your KEXT with GCC 4.0 using the -fno-threadsafe-statics compiler option, but\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 6 of 10\n\nthis may lead to other problems. Specifically, unless you can guarantee thread safety in other ways, compiling\r\nyour KEXT with this option may break your code.\r\nThe Parts of the I/O Kit\r\nPhysically and electronically, the I/O Kit is composed of many parts: frameworks and libraries, development and\r\ntesting tools, and informational resources such as example projects, documentation, and header files. This section\r\ncatalogs these parts and indicates where they are installed and how they can be accessed.\r\nFrameworks and Libraries\r\nThe I/O Kit is based on three C++ libraries. All of them are packaged in frameworks, but only IOKit.framework\r\nis a true framework. The Kernel framework exists primarily to expose kernel header files, including those of\r\nlibkern and IOKit. The code of these “libraries” is actually built into the kernel; however, drivers (when loaded)\r\ndo link against the kernel as if it were a library.\r\nTable 1-1  Frameworks and libraries of the I/O Kit\r\nFramework or\r\nlibrary\r\nDescription and location\r\nKernel/IOKit\r\nThe library used for developing kernel-resident device drivers. Headers location:\r\nKernel.framework/Headers/IOKit\r\nKernel/libkern\r\nThe library containing classes useful for all development of kernel software. Headers\r\nlocation: Kernel.framework/Headers/libkern\r\nIOKit The framework used for developing device interfaces. Location: IOKit.framework\r\nApplications and Tools\r\nYou use a handful of development applications to build, manage, debug, examine, and package device drivers.\r\nTable 1-2 lists the applications used in driver development; these applications are installed in\r\n/Developer/Applications .\r\nTable 1-2  Applications used in driver development\r\nApplication Description\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 7 of 10\n\nXcode\r\nThe primary development application for OS X. Xcode manages projects, provides a full-featured code editor, builds projects according to arbitrarily complex rules, provides a user\r\ninterface for software configuration, and acts as a front end for debugging and\r\ndocumentation searches.\r\nI/O Registry\r\nExplorer\r\nEnables the graphical exploration of the contents and structure of the I/O Registry.\r\nPackage\r\nMaker\r\nCreates an installation package for the Installer application; used for deployment of kernel\r\nextensions (including device drivers).\r\nTable 1-3 describes the command-line tools used in developing device drivers with the I/O Kit; all tools are\r\nlocated in /usr/sbin/ or /sbin .\r\nTable 1-3  Command-line tools used in driver development\r\nTool Description and location\r\nioreg\r\nPrints the contents of the I/O Registry (a command-line version of the I/O Registry\r\nExplorer application).\r\nkextload\r\nLoads a kernel extension (such as device driver) or generates a statically linked symbol file\r\nfor remote debugging.\r\nkextunload Unloads a kernel extension (if possible).\r\nkextstat Prints statistics about currently loaded drivers and other kernel extensions.\r\niostat Displays kernel I/O statistics on terminal, disk, and CPU operations.\r\nioclasscount Displays instance count of a specified class.\r\nioalloccount Displays some accounting of memory allocated by I/O Kit objects in the kernel.\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 8 of 10\n\nkextcache\r\nCompresses and archives kernel extensions (including drivers) so they can be\r\nautomatically loaded into the kernel at boot time.\r\ngcc\r\nApple’s version of the GNU C++ compiler; Xcode automatically invokes it with the\r\ncorrect set of flags for I/O Kit projects.\r\ngdb\r\nApple’s version of the GNU debugger; Xcode automatically invokes it with the correct set\r\nof flags for I/O Kit projects.\r\nOther I/O Kit Resources\r\nSeveral informational resources are included with the I/O Kit “product,” particularly documentation and header\r\nfiles. Some of these resources are described in the preceding chapter, Introduction to I/O Kit Fundamentals\r\nThe I/O Kit is part of the Darwin Open Source project. Apple maintains a website where you can find much\r\ninformation related to the I/O Kit and other Open Source projects managed by Apple. The following two locations\r\nare of particular interest:\r\nOpen Source Projects—http://developer.apple.com/darwin/projects/\r\nHere you can find links to the Darwin and Darwin Streaming projects, among other projects. Also featured\r\nare links to documentation and tools.\r\nMailing lists—http://developer.apple.com/darwin/mail.html\r\nThis page features links that will put you on the Darwin-Development and DarwinOS-Users mailing lists,\r\namong others.\r\nShould You Program in the Kernel?\r\nIf you are thinking of writing code for the kernel environment, think carefully. Programming in the kernel can be a\r\ndifficult and dangerous task. And often there is a way to accomplish what you want to do without touching the\r\nkernel.\r\nSoftware that resides in the kernel tends to be expensive. Kernel code is “wired” into physical memory and thus\r\ncannot be paged out by the virtual memory system. As more code is put into the kernel, less physical memory is\r\navailable to user-space processes. Consequently, paging activity will probably intensify, thereby degrading system\r\nperformance.\r\nKernel code is also inherently destabilizing, much more so than application code. The kernel environment is a\r\nsingle process, and this means that there is no memory protection between your driver and anything else in the\r\nkernel. Access memory in the wrong place and the entire system can grind to a halt, a victim of a kernel panic.\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 9 of 10\n\nMoreover, because kernel code usually provides services to numerous user-space clients, any inefficiencies in the\r\ncode can be propagated to those clients, thereby affecting the system globally.\r\nFinally, kernel software is a real pain to write. There are subtleties to grapple with that are unknown in the realm\r\nof application development. And bugs in kernel code are harder to find than in user-space software.\r\nWith all this in mind, the message is clear. It is in everyone's best interest to put as little code as possible into the\r\nkernel. And any code that ends up in the kernel should be honed and rigorously tested.\r\nWhen Code Should Reside in the Kernel\r\nA handful of situations warrant loading a driver or extension into the kernel environment:\r\nThe software is used by the kernel environment itself.\r\nUser-space programs will frequently use the software.\r\nThe software needs to respond directly to primary interrupts (those delivered by the CPU's interrupt\r\ncontroller).\r\nIf the software you are writing does not match any of these criteria, it probably doesn’t belong in the kernel. If\r\nyour software is a driver for a disk, a network controller, or a keyboard, it should reside in the kernel. If it is an\r\nextension to the file system, it should live in the kernel. If, on the other hand, it is used only now and then by a\r\nsingle user-space program, it should be loaded by the program and reside within it. Drivers for printers and\r\nscanners fall into this latter category.\r\nAlternatives to Kernel-Resident Code\r\nApple provides a number of technologies that might let you accomplish what you want to do and stay out of the\r\nkernel. First are the higher-level APIs that give you some hardware-level access. For example, Open Transport is a\r\npowerful resource for many networking capabilities, and Quartz Compositor enables you to do some fairly low-level things with the graphics subsystem.\r\nSecond, and just as important, is the device-interface technology of the I/O Kit framework. Through a plug-in\r\narchitecture, this technology makes it possible for your application to interact with the kernel to access hardware.\r\nIn addition, you can—with a little help from the I/O Kit—use POSIX APIs to access serial, storage, or network\r\ndevices. See Controlling Devices From Outside the Kernel for a summary of device interfaces and see the\r\ndocumentAccessing Hardware From Applications for a full discussion of this technology.\r\nSource: https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nhttps://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html\r\nPage 10 of 10",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://developer.apple.com/library/archive/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Features/Features.html"
	],
	"report_names": [
		"Features.html"
	],
	"threat_actors": [
		{
			"id": "77b28afd-8187-4917-a453-1d5a279cb5e4",
			"created_at": "2022-10-25T15:50:23.768278Z",
			"updated_at": "2026-04-10T02:00:05.266635Z",
			"deleted_at": null,
			"main_name": "Inception",
			"aliases": [
				"Inception Framework",
				"Cloud Atlas"
			],
			"source_name": "MITRE:Inception",
			"tools": [
				"PowerShower",
				"VBShower",
				"LaZagne"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "75108fc1-7f6a-450e-b024-10284f3f62bb",
			"created_at": "2024-11-01T02:00:52.756877Z",
			"updated_at": "2026-04-10T02:00:05.273746Z",
			"deleted_at": null,
			"main_name": "Play",
			"aliases": null,
			"source_name": "MITRE:Play",
			"tools": [
				"Nltest",
				"AdFind",
				"PsExec",
				"Wevtutil",
				"Cobalt Strike",
				"Playcrypt",
				"Mimikatz"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434537,
	"ts_updated_at": 1775826715,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a5e78395ffbda7e6865c569525cd1b85f81af043.pdf",
		"text": "https://archive.orkl.eu/a5e78395ffbda7e6865c569525cd1b85f81af043.txt",
		"img": "https://archive.orkl.eu/a5e78395ffbda7e6865c569525cd1b85f81af043.jpg"
	}
}