Kext utility os x 10.5 social advice Mac users interested in Kext utility os x 10.5 generally download. OpenCore is what we refer to as a 'boot loader', this is a complex piece of software that we use to prepare our systems for macOS. Specifically by injecting new data for macOS such as SMBIOS, ACPI tables and kexts. Easy Kext Installer is a minimalist Mac OS X utility that allows you to install one or several kext files with a single drag and drop action, and makes sure to perform all the necessary system maintenance tasks afterwards. Unsophisticated kernel extensions installer that is featuring a user-friendly. Easykext Utility is a Kext installer and repair permissions for OS X. And fast Kext installer and repair.caches. Install multiple kext files simultaneously. (KEXTs or Kexts) on your Mac. Extensions, (KEXTs or Kexts) on your.list of kexts to tab. My KEXT is named SteerMouse.kext, but you can replace that with the KEXT name of your choice. Once you've got it deleted, reboot your system and the KEXT will.
- Kexts For Mac Os X 10.7
- Unload Kext Mac Os X
- Kexts For Mac Os X 10.10
- Kexts For Mac Os X 10.13
- Remove Kexts Macos
- Kexts For Mac Os X 10.8
- Kexts Mac Os X
Apple regularly introduces innovative solutions and improvements to macOS. However, not all improved tools can fully replace their predecessors. This is what happened with kernel extensions and their successors, System Extensions and DriverKit.
In this article, we overview the basics of implementing macOS kernel extensions. We discuss typical tasks requiring kernel extensions as well as tools and environments for creating them. We also take a look at some peculiar aspects of creating kexts. This tutorial will be useful for macOS developers working on projects that still require the use of kernel extensions.
Contents:
Introduction to the macOS kernel and kernel extensions
The kernel is the central part of an operating system, providing applications with coordinated access to system resources: CPU, memory, external hardware, external input/output devices, and so on. The kernel usually provides access to applications' executable processes. It does so using mechanisms for interprocess communication and by providing applications with access to operating system calls.
The macOS kernel is XNU — an acronym for X is Not Unix. This hybrid kernel was developed by Apple and is used in the macOS family. In 2019, Apple introduced macOS version 10.15, also known as macOS Catalina, which contained System Extensions and DriverKit and moved most kernel APIs to the user space. This approach changed the way developers access kernel parts of the system and improved the security and stability of macOS. However, adding System Extensions and DriverKit to macOS didn't completely erase the need for kernel extensions (kexts). Let's look closer at the peculiarities of this macOS feature.
.kext kernel extensions
A kernel extension, or kext, is an application bundle used for extending the functionality of the macOS kernel. It's the minimum unit of executable code that can be loaded and used in the kernel.
Usually, there's no need for creating a kext when developing a macOS solution. The functionality available in user mode is sufficient for most tasks. Also, with the introduction of System Extensions and DriverKit, Apple has reduced the number of permitted APIs and cases where kexts can and need to be used.
But since the capabilities of System Extensions and DriverKit don't cover all kext use cases, many developers still have to build and install custom kernel extensions.
There are tasks that can't be implemented without a kernel extension, including:
- supporting a certain type of file system (including creating a new one)
- writing a specific device driver that the DriverKit API doesn't cover (for example, a graphics driver)
One of the main restrictions when creating a kext is that the code of the kext itself, as indicated in Apple's official documentation, should be essentially flawless. The reason for this strict quality requirement is simple enough: the worst-case scenario for an application is a crash and emergency exit. But if a kernel module fails, the worst-case scenario is a crash of the entire operating system and a reboot of the device. And if a kext is loaded at system startup and contains an error, it will crash the system each time it starts, thus complicating system recovery.
To avoid such unpleasant scenarios, it's crucial to ensure the highest quality of kext code. In the next section, we take a look inside a kernel extension to give you a better understanding of its structure and most important operations.
Read also:
Avoiding Kernel Development in macOS with System Extensions and DriverKit
Inside a kernel extension
Before you dive into the world of custom development of kernel extensions for macOS, you need to get familiar with the structure, enter/exit routines, and kernel–user interactions of macOS. If you already know all about this, you can move straight to the next section.
Kext bundle structure
A kext, like any other macOS application, is a bundle, only with the .kext extension. A bundle is a special folder that encapsulates application resources (in our case, kext resources).
A kext bundle must contain two files:
- a compiled binary file with executable code
- an Info.plist file containing information about the kernel extension: name, version, identifier, kernel library dependencies, etc.
Kexts For Mac Os X 10.7
Sometimes, the bundle.kext folder also contains additional files, including:
- device firmware
- resources (including those localized for use by user mode applications)
- plugins, including other kexts
Enter/exit routines
Depending on the type of extension, a kext can be written in C or C ++ and has its own peculiarities when loading to and unloading to/from the kernel:
Since this article is devoted to regular kexts, let's take a closer look at loading and unloading kernel extensions.
In kernel extension code, you must implement entry points — functions that are called when a kext is loaded to and unloaded from the kernel.
Entry points can have arbitrary names that must be specified in the project file:
Entry point functions have fixed prototypes:
As discussed in the chapter Kernel Architecture Overview,OS X provides a kernel extension mechanism as a means of allowingdynamic loading of code into the kernel, without the need to recompileor relink. Because these kernel extensions (KEXTs) provide both modularityand dynamic loadability, they are a natural choice for any relatively self-containedservice that requires access to internal kernel interfaces.
Because KEXTs run in supervisor mode in the kernel'saddress space, they are also harder to write and debug than user-levelmodules, and must conform to strict guidelines. Further, kernelresources are wired(permanently resident in memory) and are thus more costly to usethan resources in a user-space task of equivalent functionality.
In addition, although memory protection keeps applicationsfrom crashing the system, no such safeguards are in place insidethe kernel. A badly behaved kernel extension in OS X can causeas much trouble as a badly behaved application or extension couldin Mac OS 9.
Unload Kext Mac Os X
Bugs in KEXTs can have far more severe consequences than bugsin user-level code. For example, a memory access error in a userapplication can, at worst, cause that application to crash. In contrast,a memory access error in a KEXT causes a kernel panic, crashingthe operating system.
Finally, for security reasons, some customersrestrict or don't permit the use of third-party KEXTs. As a result,use of KEXTs is strongly discouraged in situations where user-level solutionsare feasible. OS X guarantees that threading in applications is just asefficient as threading inside the kernel, so efficiency should notbe an issue. Unless your application requires low-level access tokernel interfaces, you should use a higher level of abstraction whendeveloping code for OS X.
When you are trying to determine if a piece of code shouldbe a KEXT, the default answer is generally no. Adobe reader 10 for mac free download. Even if your code was a system extension in Mac OS 9, that doesnot necessarily mean that it should be a kernel extension in OS X. There are only a few good reasons for a developer to writea kernel extension:
Your codeneeds to take a primary interrupt—that is, something in the (built-in) hardwareneeds to interrupt the CPU and execute a handler.
The primary client of your code is inside the kernel—forexample, a block device whose primary client is a file system.
Your code needs to access kernel interfaces that are not exportedto user space.
Your code has other special requirements that cannot be satisfiedin a user space application.
If your code does not meet any of the above criteria (andpossibly even if it does), you should consider developing it asa library or a user-level daemon, or using one of the user-levelplug-in architectures (such as QuickTimecomponents or the CoreGraphics framework) instead of writing a kernel extension.
If you are writing device drivers or code to support a newvolume format or networking protocol, however, KEXTs may be theonly feasible solution. Fortunately, while KEXTs may be more difficultto write than user-space code, several tools and procedures are availableto enhance the development and debugging process. See Debugging Your KEXT formore information.
This chapter provides a conceptual overview of KEXTs and howto create them. If you are interested in building a simple KEXT,see the Apple tutorials listed in the bibliography. These providestep-by-step instructions for creating a simple, generic KEXT ora basic I/O Kit driver.
Implementation of a KernelExtension (KEXT)
Kernel extensions are implemented asbundles,folders that the Finder treats as single files. See the chapterabout bundles in Mac Technology Overview for a discussion of bundles.The KEXTbundle can contain the following:
Informationproperty list—a text file that describes the contents,settings, and requirements of the KEXT. This file is required. AKEXT bundle need contain nothing more than this file, although mostKEXTs contain one or more kernel modules as well. See the chapterabout software configuration in Mac Technology Overview for further information about propertylists.
KEXT binary—a file in Mach-O format, containing the actualbinary code used by the KEXT. A KEXT binary (also known as a kernelmodule or KMOD)represents the minimum unit of code that can be loaded into thekernel. A KEXT usually contains one KEXT binary. If no KEXT binariesare included, the information property list file must contain areference to another KEXT and change its default settings.
Resources—for example, icons or localizationdictionaries. Resources are optional; they may be useful for a KEXTthat needs to display a dialog or menu. At present, no resourcesare explicitly defined for use with KEXTs.
KEXT bundles—a kext can contain otherKEXTs. This can be used for plug-ins that augment features of aKEXT.
Kernel Extension Dependencies
Any KEXT can declare that it is dependent upon any other KEXT. The developer lists these dependencies in the OSBundleLibraries dictionary in the module's property list file.
Before a KEXT is loaded, all of its requirements are checked.Those required extensions (and their requirements) are loaded first,iterating back through the lists until there are no more requiredextensions to load. Only after all requirements are met, is therequested KEXT loaded as well.
For example, device drivers (a type of KEXT) are dependentupon (require) certain families (another type of KEXT). When a driveris loaded, its required families are also loaded to provide necessary,common functionality. To ensure that all requirements are met, each devicedriver should list all of its requirements (families and other drivers)in its property list. See the chapter I/O Kit Overview, for an explanationof drivers and families.
It is important to list all dependencies for each KEXT. Ifyour KEXT fails to do so, your KEXT may not load due to unrecognizedsymbols, thus rendering the KEXT useless. Dependencies in KEXTscan be considered analogous to required header files or libraries incode development; in fact, the Kernel Extension Manageruses the standard linker to resolve KEXT requirements.
Building and Testing Your Extension
After creating the necessary property list and C or C++ source files, you use Project Builder tobuild your KEXT. Any errors in the source code are brought to yourattention during the build and you are given the chance to edityour source files and try again.
To test your KEXT, however, you need to leave Project Builderand work in the Terminal application(or in console mode).In console mode, all system messages are written directly to yourscreen, as well as to a log file (/var/log/system.log).If you work in the Terminal application, you must view system messagesin the log file or in the Console application.You also need to login to the root account (or use the su or sudo command), sinceonly the root account can load kernel extensions.
Kexts For Mac Os X 10.10
When testing your KEXT, you can load and unload it manually,as well as check the load status. You can use the kextload commandto load any KEXT. A manual page for kextload isincluded in OS X. (On OS X prior to 10.2, you must use the kmodload command instead.)
Note that this command is useful only when developing a KEXT.Eventually, after it has been tested and debugged, you install yourKEXT in one of the standard places (see Installed KEXTs for details).Then, it will be loaded and unloaded automatically at system startupand shutdown or whenever it is needed (such as when a new deviceis detected).
Kexts For Mac Os X 10.13
Debugging Your KEXT
Remove Kexts Macos
KEXT debuggingcan be complicated. Before you can debug a KEXT, you must firstenable kernel debugging, as OS X is not normally configuredto permit debugging the kernel. Only the root account can enablekernel debugging, and you need to reboot OS X for the changesto take effect. (You can use sudo to gainroot privileges if you don't want to enable a root password.)
Kernel debugging is performed using two OS X computers,called the development or debug host and the debug target. Thesecomputers must be connected over a reliable network connection onthe same subnet (or within a single local network). Specifically, theremust not be any intervening IP routers or other devices that couldmake hardware-based Ethernet addressing impossible.
The KEXT is registered (and loaded and run) on the target.The debugger is launched and run on the debug host. You can alsorebuild your KEXT on the debug host, after you fix any errors youfind.
Debugging must be performed in this fashion because you musttemporarily halt the kernel on the target in order to use the debugger.When you halt the kernel, all other processes on that computer stop.However, a debugger running remotely can continue to run and cancontinue to examine (or modify) the kernel on the target.
Note that bugs in KEXTs may cause the target kernel to freezeor panic. If this happens, you may not be able to continue debugging,even over a remote connection; you have to reboot the target andstart over, setting a breakpoint just before the code where theKEXT crashed and working very carefully up to the crash point.
Developers generally debug KEXTs using gdb,a source-level debugger with a command-line interface. You willneed to work in the Terminal application to run gdb.For detailed information about using gdb,see the documentation included with OS X. You can also use the help commandfrom within gdb.
Some features of gdb areunavailable when debugging KEXTs because of implementation limitations.For example:
You can'tuse
gdbto call a functionor method in a KEXT.You should not use
gdbtodebug interrupt routines.
The former is largely a barrier introduced by the C++ language.The latter may work in some cases but is not recommended due tothe potential for gdb to interrupt something uponwhich kdp (the kernel shim used by gdb)depends in order to function properly.
Use care that you do not halt the kernel for too long whenyou are debugging (for example, when you set breakpoints). In ashort time, internal inconsistencies can appear that cause the targetkernel to panic or freeze, forcing you to reboot the target.
Additional information about debugging can be found in When Things Go Wrong: Debugging the Kernel.
Installed KEXTs
Kexts For Mac Os X 10.7
Sometimes, the bundle.kext folder also contains additional files, including:
- device firmware
- resources (including those localized for use by user mode applications)
- plugins, including other kexts
Enter/exit routines
Depending on the type of extension, a kext can be written in C or C ++ and has its own peculiarities when loading to and unloading to/from the kernel:
Since this article is devoted to regular kexts, let's take a closer look at loading and unloading kernel extensions.
In kernel extension code, you must implement entry points — functions that are called when a kext is loaded to and unloaded from the kernel.
Entry points can have arbitrary names that must be specified in the project file:
Entry point functions have fixed prototypes:
As discussed in the chapter Kernel Architecture Overview,OS X provides a kernel extension mechanism as a means of allowingdynamic loading of code into the kernel, without the need to recompileor relink. Because these kernel extensions (KEXTs) provide both modularityand dynamic loadability, they are a natural choice for any relatively self-containedservice that requires access to internal kernel interfaces.
Because KEXTs run in supervisor mode in the kernel'saddress space, they are also harder to write and debug than user-levelmodules, and must conform to strict guidelines. Further, kernelresources are wired(permanently resident in memory) and are thus more costly to usethan resources in a user-space task of equivalent functionality.
In addition, although memory protection keeps applicationsfrom crashing the system, no such safeguards are in place insidethe kernel. A badly behaved kernel extension in OS X can causeas much trouble as a badly behaved application or extension couldin Mac OS 9.
Unload Kext Mac Os X
Bugs in KEXTs can have far more severe consequences than bugsin user-level code. For example, a memory access error in a userapplication can, at worst, cause that application to crash. In contrast,a memory access error in a KEXT causes a kernel panic, crashingthe operating system.
Finally, for security reasons, some customersrestrict or don't permit the use of third-party KEXTs. As a result,use of KEXTs is strongly discouraged in situations where user-level solutionsare feasible. OS X guarantees that threading in applications is just asefficient as threading inside the kernel, so efficiency should notbe an issue. Unless your application requires low-level access tokernel interfaces, you should use a higher level of abstraction whendeveloping code for OS X.
When you are trying to determine if a piece of code shouldbe a KEXT, the default answer is generally no. Adobe reader 10 for mac free download. Even if your code was a system extension in Mac OS 9, that doesnot necessarily mean that it should be a kernel extension in OS X. There are only a few good reasons for a developer to writea kernel extension:
Your codeneeds to take a primary interrupt—that is, something in the (built-in) hardwareneeds to interrupt the CPU and execute a handler.
The primary client of your code is inside the kernel—forexample, a block device whose primary client is a file system.
Your code needs to access kernel interfaces that are not exportedto user space.
Your code has other special requirements that cannot be satisfiedin a user space application.
If your code does not meet any of the above criteria (andpossibly even if it does), you should consider developing it asa library or a user-level daemon, or using one of the user-levelplug-in architectures (such as QuickTimecomponents or the CoreGraphics framework) instead of writing a kernel extension.
If you are writing device drivers or code to support a newvolume format or networking protocol, however, KEXTs may be theonly feasible solution. Fortunately, while KEXTs may be more difficultto write than user-space code, several tools and procedures are availableto enhance the development and debugging process. See Debugging Your KEXT formore information.
This chapter provides a conceptual overview of KEXTs and howto create them. If you are interested in building a simple KEXT,see the Apple tutorials listed in the bibliography. These providestep-by-step instructions for creating a simple, generic KEXT ora basic I/O Kit driver.
Implementation of a KernelExtension (KEXT)
Kernel extensions are implemented asbundles,folders that the Finder treats as single files. See the chapterabout bundles in Mac Technology Overview for a discussion of bundles.The KEXTbundle can contain the following:
Informationproperty list—a text file that describes the contents,settings, and requirements of the KEXT. This file is required. AKEXT bundle need contain nothing more than this file, although mostKEXTs contain one or more kernel modules as well. See the chapterabout software configuration in Mac Technology Overview for further information about propertylists.
KEXT binary—a file in Mach-O format, containing the actualbinary code used by the KEXT. A KEXT binary (also known as a kernelmodule or KMOD)represents the minimum unit of code that can be loaded into thekernel. A KEXT usually contains one KEXT binary. If no KEXT binariesare included, the information property list file must contain areference to another KEXT and change its default settings.
Resources—for example, icons or localizationdictionaries. Resources are optional; they may be useful for a KEXTthat needs to display a dialog or menu. At present, no resourcesare explicitly defined for use with KEXTs.
KEXT bundles—a kext can contain otherKEXTs. This can be used for plug-ins that augment features of aKEXT.
Kernel Extension Dependencies
Any KEXT can declare that it is dependent upon any other KEXT. The developer lists these dependencies in the OSBundleLibraries dictionary in the module's property list file.
Before a KEXT is loaded, all of its requirements are checked.Those required extensions (and their requirements) are loaded first,iterating back through the lists until there are no more requiredextensions to load. Only after all requirements are met, is therequested KEXT loaded as well.
For example, device drivers (a type of KEXT) are dependentupon (require) certain families (another type of KEXT). When a driveris loaded, its required families are also loaded to provide necessary,common functionality. To ensure that all requirements are met, each devicedriver should list all of its requirements (families and other drivers)in its property list. See the chapter I/O Kit Overview, for an explanationof drivers and families.
It is important to list all dependencies for each KEXT. Ifyour KEXT fails to do so, your KEXT may not load due to unrecognizedsymbols, thus rendering the KEXT useless. Dependencies in KEXTscan be considered analogous to required header files or libraries incode development; in fact, the Kernel Extension Manageruses the standard linker to resolve KEXT requirements.
Building and Testing Your Extension
After creating the necessary property list and C or C++ source files, you use Project Builder tobuild your KEXT. Any errors in the source code are brought to yourattention during the build and you are given the chance to edityour source files and try again.
To test your KEXT, however, you need to leave Project Builderand work in the Terminal application(or in console mode).In console mode, all system messages are written directly to yourscreen, as well as to a log file (/var/log/system.log).If you work in the Terminal application, you must view system messagesin the log file or in the Console application.You also need to login to the root account (or use the su or sudo command), sinceonly the root account can load kernel extensions.
Kexts For Mac Os X 10.10
When testing your KEXT, you can load and unload it manually,as well as check the load status. You can use the kextload commandto load any KEXT. A manual page for kextload isincluded in OS X. (On OS X prior to 10.2, you must use the kmodload command instead.)
Note that this command is useful only when developing a KEXT.Eventually, after it has been tested and debugged, you install yourKEXT in one of the standard places (see Installed KEXTs for details).Then, it will be loaded and unloaded automatically at system startupand shutdown or whenever it is needed (such as when a new deviceis detected).
Kexts For Mac Os X 10.13
Debugging Your KEXT
Remove Kexts Macos
KEXT debuggingcan be complicated. Before you can debug a KEXT, you must firstenable kernel debugging, as OS X is not normally configuredto permit debugging the kernel. Only the root account can enablekernel debugging, and you need to reboot OS X for the changesto take effect. (You can use sudo to gainroot privileges if you don't want to enable a root password.)
Kernel debugging is performed using two OS X computers,called the development or debug host and the debug target. Thesecomputers must be connected over a reliable network connection onthe same subnet (or within a single local network). Specifically, theremust not be any intervening IP routers or other devices that couldmake hardware-based Ethernet addressing impossible.
The KEXT is registered (and loaded and run) on the target.The debugger is launched and run on the debug host. You can alsorebuild your KEXT on the debug host, after you fix any errors youfind.
Debugging must be performed in this fashion because you musttemporarily halt the kernel on the target in order to use the debugger.When you halt the kernel, all other processes on that computer stop.However, a debugger running remotely can continue to run and cancontinue to examine (or modify) the kernel on the target.
Note that bugs in KEXTs may cause the target kernel to freezeor panic. If this happens, you may not be able to continue debugging,even over a remote connection; you have to reboot the target andstart over, setting a breakpoint just before the code where theKEXT crashed and working very carefully up to the crash point.
Developers generally debug KEXTs using gdb,a source-level debugger with a command-line interface. You willneed to work in the Terminal application to run gdb.For detailed information about using gdb,see the documentation included with OS X. You can also use the help commandfrom within gdb.
Some features of gdb areunavailable when debugging KEXTs because of implementation limitations.For example:
You can'tuse
gdbto call a functionor method in a KEXT.You should not use
gdbtodebug interrupt routines.
The former is largely a barrier introduced by the C++ language.The latter may work in some cases but is not recommended due tothe potential for gdb to interrupt something uponwhich kdp (the kernel shim used by gdb)depends in order to function properly.
Use care that you do not halt the kernel for too long whenyou are debugging (for example, when you set breakpoints). In ashort time, internal inconsistencies can appear that cause the targetkernel to panic or freeze, forcing you to reboot the target.
Additional information about debugging can be found in When Things Go Wrong: Debugging the Kernel.
Installed KEXTs
The Kernel Extension Manager (KEXT Manager) is responsiblefor loading and unloading all installed KEXTs (commands such as kextload areused only during development). Installed KEXTs are dynamically addedto the running OS X kernel as part of the kernel's addressspace. An installed and enabled KEXT is invoked as needed.
Important: Note that KEXTs are only wrappers (bundles) arounda property list, KEXT binaries (or references to other KEXTs), andoptional resources. The KEXT describes what is to be loaded; itis the KEXT binaries that are actually loaded.
KEXTs are usually installed in the folder /System/Libraries/Extensions.The Kernel Extension Manager (in the form of a daemon, kextd),always checks here. KEXTs can also be installed in ROM or insidean application bundle.
Installing KEXTs in an application bundle allows an applicationto register those KEXTs without the need to install them permanentlyelsewhere within the system hierarchy. This may be more convenientand allows the KEXT to be associated with a specific, running application.When it starts, the application can register the KEXT and, if desired,unregister it on exit.
For example, a network packet sniffer application might employa Network Kernel Extension (NKE). A tape backup application wouldrequire that a tape driver be loaded during the duration of thebackup process. When the application exits, the kernel extension isno longer needed and can be unloaded.
Note that, although the application is responsible for registeringthe KEXT, this is no guarantee that the corresponding KEXTs areactually ever loaded. It is still up to a kernel component, suchas the I/O Kit, to determine a need, such as matching a piece ofhardware to a desired driver, thus causing the appropriate KEXTs(and their dependencies) to be loaded.
Kexts For Mac Os X 10.8
Kexts Mac Os X
Copyright © 2002, 2013 Apple Inc. All Rights Reserved. Terms of Use | Privacy Policy | Updated: 2013-08-08
