Apple что такое kernel extension

Kernel extensions in macOS

Starting with macOS 11 , if third-party kernel extensions (kexts) are enabled, they can’t be loaded into the kernel on demand. Instead, they’re merged into an Auxiliary Kernel Collection (AuxKC), which is loaded during the boot process. For a Mac with Apple silicon, the measurement of the AuxKC is signed into the LocalPolicy (for previous hardware, the AuxKC resided on the data volume). Rebuilding the AuxKC requires the user’s approval and restarting of the macOS to load the changes into the kernel, and it requires that the secure boot be configured to Reduced Security.

Important: Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system, and Apple recommends users select solutions that don’t require extending the kernel.

Kernel extensions in a Mac with Apple silicon

Kexts must be explicitly enabled for a Mac with Apple silicon by holding the power button at startup to enter into One True Recovery (1TR) mode, then downgrading to Reduced Security and checking the box to enable kernel extensions. This action also requires entering an administrator password to authorize the downgrade. The combination of the 1TR and password requirement makes it difficult for software-only attackers starting from within macOS to inject kexts into macOS, which they can then exploit to gain kernel privileges.

After a user authorizes kexts to load, the above User-Approved Kernel Extension Loading flow is used to authorize the installation of kexts. The authorization used for the above flow is also used to capture an SHA384 hash of the user-authorized kext list (UAKL) in the LocalPolicy. The kernel management daemon ( kmd ) is then responsible for validating only those kexts found in the UAKL for inclusion into the AuxKC.

If System Integrity Protection (SIP) is enabled, the signature of each kext is verified before being included in the AuxKC.

If SIP is disabled, the kext signature isn’t enforced.

This approach allows Permissive Security flows for developers or users who aren’t part of the Apple Developer Program to test kexts before they are signed.

After the AuxKC is created, its measurement is sent to the Secure Enclave to be signed and included in an Image4 data structure that can be evaluated by iBoot at startup. As part of the AuxKC construction, a kext receipt is also generated. This receipt contains the list of kexts that were actually included in the AuxKC, because the set could be a subset of the UAKL if banned kexts were encountered. An SHA384 hash of the AuxKC Image4 data structure and the kext receipt are included in the LocalPolicy. The AuxKC Image4 hash is used for extra verification by iBoot at startup to help ensure that it isn’t possible to start up an older Secure Enclave–signed AuxKC Image4 file with a newer LocalPolicy. The kext receipt is used by subsystems such as Apple Pay to determine whether there are any kexts currently loaded that could interfere with the trustworthiness of macOS. If there are, then Apple Pay capabilities may be disabled.

Alternatives to kexts (macOS 10.15 or later)

macOS 10.15 enables developers to extend the capabilities of macOS by installing and managing system extensions that run in user space rather than at the kernel level. By running in user space, system extensions increase the stability and security of macOS. Even though kexts inherently have full access to the entire operating system, extensions running in user space are granted only the privileges necessary to perform their specified function.

Developers can use frameworks, including DriverKit, EndpointSecurity, and NetworkExtension, to write USB and human interface drivers, endpoint security tools (like data loss prevention or other endpoint agents), and VPN and network tools, all without needing to write kexts. Third-party security agents should be used only if they take advantage of these APIs or have a robust road map to transition to them and away from kernel extensions.

User-Approved Kernel Extension Loading

To improve security, user consent is required to load kernel extensions installed with or after installing macOS 10.13 . This process is known as User-Approved Kernel Extension Loading. Administrator authorization is required to approve a kernel extension. Kernel extensions don’t require authorization if they:

Were installed on a Mac when running macOS 10.12 or earlier

Are replacing previously approved extensions

Are allowed to load without user consent by using the spctl command-line tool available when a Mac was booted from recoveryOS

Are allowed to load using mobile device management (MDM) configuration

Starting with macOS 10.13.2 , users can use MDM to specify a list of kernel extensions that load without user consent. This option requires a Mac running macOS 10.13.2 that’s enrolled in MDM—through Apple School Manager, Apple Business Manager, or user-approved MDM enrollment.

Источник

Deprecated Kernel Extensions and System Extension Alternatives

System extensions on macOS Catalina 10.15 or later allow software, such as network extensions and endpoint security solutions, to extend the functionality of macOS without requiring kernel-level access. As part of our ongoing effort to modernize the platform, improve security and reliability, and enable more user-friendly distribution methods, kernel extensions have been deprecated. Starting with macOS Big Sur, macOS releases no longer load kernel extensions that use deprecated kernel programming interfaces (KPIs) by default.

Transitioning your kernel extensions

Certain kernel extensions are unsupported on macOS Big Sur. If your software uses deprecated and supported KPIs for older versions of macOS, you’ll need to factor out deprecated components into a stand-alone system extension. If your software uses new system extensions and legacy kernel extensions, you can distribute to supported operating systems. Software that supports a broad range of macOS versions should continue to use kernel extensions for older versions and run system extensions where supported.

Below is a list of unsupported KPIs as of macOS Big Sur. Any kernel extension using an unsupported KPI will not load.*

KAUTH

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

The following KPIs are unsupported in macOS Big Sur. Clients should use EndpointSecurity instead.

Socket

Deprecated: macOS Catalina 10.15

The following Socket KPIs continue to be deprecated in macOS Big Sur. Clients should use NetworkExtension instead.

• sock_accept
• sock_bind
• sock_close
• sock_connect
• sock_getpeername
• sock_getsockname
• sock_getsockopt
• sock_gettype
• sock_ioctl
• sock_isconnected
• sock_isnonblocking
• sock_listen
• sock_receive
• sock_receivembuf
• sock_release
• sock_retain
• sock_send
• sock_sendmbuf
• sock_setsockopt
• sock_shutdown
• sock_socket

Network filter

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

The following Network Filter KPIs are unsupported in macOS Big Sur:

• ipf_addv4
• ipf_addv6
• ipf_inject_input
• ipf_inject_output
• ipf_remove
• sflt_attach
• sflt_detach
• sflt_register
• sflt_unregister
• sock_inject_data_in
• sock_inject_data_out
• sock_setpriv
• sockopt_copyin
• sockopt_copyout
• sockopt_direction
• sockopt_level
• sockopt_name
• sockopt_valsize

IOHIDFamily

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

All KPIs in IOHIDFamily are unsupported in macOS Big Sur. Clients should use HIDDriverKit instead.

IOUSBFamily

Unsupported: macOS Big Sur 11.0
Deprecated: OS X El Capitan 10.11

All KPIs in IOUSBFamily are unsupported in macOS Big Sur. Clients should move to IOUSBHostFamily or USBDriverKit, where appropriate and as outlined below.

USB networking

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

The combination of using IONetworkingFamily KPIs as well as any USB KPI (IOUSBHostFamily or IOUSBFamily) is unsupported in macOS Big Sur. USB KPIs have alternatives in USBDriverKit. Clients of IONetworkingFamily KPIs should use NetworkingDriverKit instead.

USB serial

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

The combination of using any IOSerialFamily KPI as well as any USB KPI (IOUSBHostFamily or IOUSBFamily) is unsupported in macOS Big Sur. USB KPIs have alternatives in USBDriverKit. Clients of IOSerialFamily KPIs should use SerialDriverKit or USBSerialDriverKit instead.

USB vendor-specific IPC

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

Any kernel extension using USB KPI (IOUSBHostFamily or IOUSBFamily) that doesn’t tie into the IO Family subsystem and uses IOUserClient, or subclasses, for IPC is unsupported in macOS Big Sur. USB KPIs have alternatives in USBDriverKit or consider IOUSBHost framework. DriverKit also has mechanisms for communication channels.

PCI networking

Unsupported: macOS Big Sur 11.0
Deprecated: macOS Catalina 10.15

The combination of using IONetworkingFamily KPIs as well as IOPCIFamily KPIs is deprecated. PCI KPIs have alternatives in PCIDriverKit. Clients of IONetworkingFamily KPIs should use NetworkingDriverKit instead.

Contacting us

Entitlements

To deploy drivers built with DriverKit or use the EndpointSecurity API, you’ll need an entitlement from Apple.

Feedback

Your feedback is valuable and helps inform the direction of our system extension development. Send us your API enhancement requests or bug reports through Feedback Assistant.

• *Kernel extension deprecation policies are not enforced when SIP is disabled or if a kernel extension is approved through a MDM profile.

Feedback Assistant

Submit bug reports and request enhancements to APIs and developer tools.

Send us feedback

Developer Forums

Ask questions and find answers by Apple engineers and other developers.

Contact Us

Tell us how we can help and we’ll find a solution by phone or email.

Источник

Kernel extensions in macOS

Starting with macOS 11 , if third-party kernel extensions (kexts) are enabled, they can’t be loaded into the kernel on demand. Instead, they’re merged into an Auxiliary Kernel Collection (AuxKC), which is loaded during the boot process. For a Mac with Apple silicon, the measurement of the AuxKC is signed into the LocalPolicy (for previous hardware, the AuxKC resided on the data volume). Rebuilding the AuxKC requires the user’s approval and restarting of the macOS to load the changes into the kernel, and it requires that the secure boot be configured to Reduced Security.

Important: Kexts are no longer recommended for macOS. Kexts risk the integrity and reliability of the operating system, and Apple recommends users select solutions that don’t require extending the kernel.

Kernel extensions in a Mac with Apple silicon

Kexts must be explicitly enabled for a Mac with Apple silicon by holding the power button at startup to enter into One True Recovery (1TR) mode, then downgrading to Reduced Security and checking the box to enable kernel extensions. This action also requires entering an administrator password to authorize the downgrade. The combination of the 1TR and password requirement makes it difficult for software-only attackers starting from within macOS to inject kexts into macOS, which they can then exploit to gain kernel privileges.

After a user authorizes kexts to load, the above User-Approved Kernel Extension Loading flow is used to authorize the installation of kexts. The authorization used for the above flow is also used to capture an SHA384 hash of the user-authorized kext list (UAKL) in the LocalPolicy. The kernel management daemon ( kmd ) is then responsible for validating only those kexts found in the UAKL for inclusion into the AuxKC.

If System Integrity Protection (SIP) is enabled, the signature of each kext is verified before being included in the AuxKC.

If SIP is disabled, the kext signature isn’t enforced.

This approach allows Permissive Security flows for developers or users who aren’t part of the Apple Developer Program to test kexts before they are signed.

After the AuxKC is created, its measurement is sent to the Secure Enclave to be signed and included in an Image4 data structure that can be evaluated by iBoot at startup. As part of the AuxKC construction, a kext receipt is also generated. This receipt contains the list of kexts that were actually included in the AuxKC, because the set could be a subset of the UAKL if banned kexts were encountered. An SHA384 hash of the AuxKC Image4 data structure and the kext receipt are included in the LocalPolicy. The AuxKC Image4 hash is used for extra verification by iBoot at startup to help ensure that it isn’t possible to start up an older Secure Enclave–signed AuxKC Image4 file with a newer LocalPolicy. The kext receipt is used by subsystems such as Apple Pay to determine whether there are any kexts currently loaded that could interfere with the trustworthiness of macOS. If there are, then Apple Pay capabilities may be disabled.

Alternatives to kexts (macOS 10.15 or later)

macOS 10.15 enables developers to extend the capabilities of macOS by installing and managing system extensions that run in user space rather than at the kernel level. By running in user space, system extensions increase the stability and security of macOS. Even though kexts inherently have full access to the entire operating system, extensions running in user space are granted only the privileges necessary to perform their specified function.

Developers can use frameworks, including DriverKit, EndpointSecurity, and NetworkExtension, to write USB and human interface drivers, endpoint security tools (like data loss prevention or other endpoint agents), and VPN and network tools, all without needing to write kexts. Third-party security agents should be used only if they take advantage of these APIs or have a robust road map to transition to them and away from kernel extensions.

User-Approved Kernel Extension Loading

To improve security, user consent is required to load kernel extensions installed with or after installing macOS 10.13 . This process is known as User-Approved Kernel Extension Loading. Administrator authorization is required to approve a kernel extension. Kernel extensions don’t require authorization if they:

Were installed on a Mac when running macOS 10.12 or earlier

Are replacing previously approved extensions

Are allowed to load without user consent by using the spctl command-line tool available when a Mac was booted from recoveryOS

Are allowed to load using mobile device management (MDM) configuration

Starting with macOS 10.13.2 , users can use MDM to specify a list of kernel extensions that load without user consent. This option requires a Mac running macOS 10.13.2 that’s enrolled in MDM—through Apple School Manager, Apple Business Manager, or user-approved MDM enrollment.

Источник