Hello @all I'm develop a DriverKit driver extension and without entitlement checks by OS everything runs fine. But if the entitlements check is enabled in the NVRAM then I get an error due connecting my IOUserClient instance. Which entitlements are really and exactly required for my driver? My driver contains: one IOUserClient instance and multiple IOUserSerial instances The bundle identifier of the driver ist: org.eof.tools.VSPDriver The bundle identifier of the client app org.eof.tools.VSPInstall My entire source code is available on GitHub if any one want to dive deep in :) kernel[0:5107] () [VSPDriver]: NewUserClient called. kernel[0:5107] () [VSPDriver]: CreateUserClient: create VSP user client from Info.plist. kernel[0:5107] () [VSPUserClient]: init called. kernel[0:5107] () [VSPUserClient]: init finished. kernel[0:5107] () [VSPDriver]: CreateUserClient: check VSPUserClient type. kernel[0:5107] () [VSPDriver]: CreateUserClient: success. kernel[0:5107] () [VSPDriver]: NewUserClient finished. kernel[0:5107] () [VSPUserClient]: Start: called. kernel[0:5107] () [VSPUserClient]: User client successfully started. kernel[0:389f] DK: VSPUserClient-0x100001127:UC failed userclient-access check, needed bundle ID org.eof.tools.VSPDriver kernel[0:389f] DK: VSPUserClient-0x100001127:UC entitlements check failed kernel[0:5107] () [VSPUserClient]: Stop called. kernel[0:5107] () [VSPUserClient]: User client successfully removed. kernel[0:5107] () [VSPUserClient]: free called. Here my drivers entitlement file: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.family.serial</key> <true/> </dict> </plist> Here my drivers Info.plist file <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>NSHumanReadableCopyright</key> <string>Copyright © 2025 by EoF Software Labs</string> <key>OSBundleUsageDescription</key> <string>Provide virtual serial port</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-any-userclient-access</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.system-extension.redistributable</key> <true/> <key>OSBundleLibraries</key> <dict> <key>com.apple.iokit.IOSerialFamily</key> <string>1.0</string> </dict> <key>IOKitPersonalities</key> <dict> <key>VSPDriver</key> <dict> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleIdentifierKernel</key> <string>com.apple.kpi.iokit</string> <key>IOMatchCategory</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>IOProviderClass</key> <string>IOUserResources</string> <key>IOResourceMatch</key> <string>IOKit</string> <key>IOProbeScore</key> <integer>0</integer> <key>IOClass</key> <string>IOUserService</string> <key>IOUserClass</key> <string>VSPDriver</string> <key>IOUserServerName</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>UserClientProperties</key> <dict> <key>IOClass</key> <string>IOUserUserClient</string> <key>IOUserClass</key> <string>VSPUserClient</string> </dict> <key>SerialPortProperties</key> <dict> <key>CFBundleIdentifierKernel</key> <string>com.apple.driver.driverkit.serial</string> <key>IOProviderClass</key> <string>IOSerialStreamSync</string> <key>IOClass</key> <string>IOUserSerial</string> <key>IOUserClass</key> <string>VSPSerialPort</string> <key>HiddenPort</key> <false/> <key>IOTTYBaseName</key> <string>vsp</string> <key>IOTTYSuffix</key> <string>0</string> </dict> </dict> </dict> </dict> </plist> Here the entitlements of the client app <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.allow-third-party-userclients</key> <true/> <key>com.apple.developer.driverkit.communicates-with-drivers</key> <true/> <key>com.apple.developer.shared-with-you</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.security.application-groups</key> <array> <string>$(TeamIdentifierPrefix).org.eof.apps</string> </array> </dict> </plist> Here the Info.plist of the client app: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleExecutable</key> <string>$(EXECUTABLE_NAME)</string> <key>CFBundleIdentifier</key> <string>$(PRODUCT_BUNDLE_IDENTIFIER)</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundleName</key> <string>$(PRODUCT_NAME)</string> <key>CFBundlePackageType</key> <string>$(PRODUCT_BUNDLE_PACKAGE_TYPE)</string> <key>CFBundleShortVersionString</key> <string>1.0</string> <key>CFBundleVersion</key> <string>1</string> <key>LSMinimumSystemVersion</key> <string>$(MACOSX_DEPLOYMENT_TARGET)</string> <key>com.apple.developer.driverkit</key> <true/> <key>com.apple.developer.driverkit.install</key> <true/> <key>com.apple.developer.system-extension.install</key> <true/> <key>com.apple.developer.system-extension.uninstall</key> <true/> <key>com.apple.developer.driverkit.userclient-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.private.driverkit.driver-access</key> <array> <string>VSPDriver</string> </array> <key>com.apple.security.temporary-exception.iokit-user-client-class</key> <array> <string>IOUserUserClient</string> </array> </dict> </plist>

Hello everyone. After a lot of research and some tests from various sources, I have actually built a small SerialDriverKit IOUserSerial driver. Unfortunately, the documentation on the official sites is tight-lipped and very thin. At least I have a running driver instance. Now my request and question: Can anyone give me a tip on how to get the data from the serial client? I have already called IOUserSerial::ConnectQueues(...) in the IOUserSerial::Start() method and I got the IOMemoryDescriptors for interrupt, RX and TX to my driver instance. I tried to get access to the memory in the method IOUserSerial::TxDataAvailable() with IOMemoryDescriptor::CreateMapping(...). Unfortunately, no data is coming in. It's always 0x00. Here is the OS log: kernel: (org.eof.tools.VSPDriver.dext) kernel: (org.eof.tools.VSPDriver.dext) [VSPDriver] init called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] constructor called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriver] start called. kernel: (org.eof.tools.VSPDriver.dext) IOUserSerial::: 40 0x600000da4058 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] Start called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] Connect INT/RX/TX buffer. kernel: (org.eof.tools.VSPDriver.dext) IOUserSerial::: 59 0x600000da4058 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] prepare TCP socket. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriver] driver started successfully. kernel: DK: VSPDriver-0x100000753::start(IOUserResources-0x100000116) ok ... ... some client serial setup stuff ... kernel: (IOUserSerial) IOUserSerial::hwResetFIFO: 1076 ==&gt;0 kernel: (IOUserSerial) IOUserSerial::hwResetFIFO: 1076 &lt;== kernel: (IOUserSerial) IOUserSerial::hwResetFIFO: 1076 locklevel = 1 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriver] HwResetFIFO called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] HwResetFIFO called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] HwResetFIFO: tx=0 rx=1 kernel: (IOUserSerial) IOUserSerial::hwResetFIFO: 1076 ==&gt;0 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriver] TxDataAvailable called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable called. kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: address=0x104c22000 length=16384 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: debug TX buffer kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00 kernel: (org.eof.tools.VSPDriver.dext) [VSPDriverPrivate] TxDataAvailable: TX&gt; 0x00

Hello everyone, We are migrating a KEXT storage driver to DriverKit. In our KEXT, we use a "one LUN = one Target" model and successfully create multiple targets in a loop during initialization. We are now trying to replicate this architecture in our DEXT. The issue is that only Target 0 is fully probed and mounted. For Target 1, the lifecycle silently stops after the first TEST UNIT READY command is successfully acknowledged. The macOS SCSI layer never sends any subsequent probe commands (like INQUIRY) to this target. The failure sequence for Target 1, observed from our logs (regardless of whether Target 0 is created), is as follows: AsyncCreateTargetForID(1) -> UserInitializeTargetForID(1) (Succeeds) UserProcessParallelTask(Target: 1, Opcode: TUR) (Succeeds) The DEXT correctly acknowledges the TUR command for Target 1 by returning kSCSITaskStatus_CHECK_CONDITION with UNIT ATTENTION in the Sense Data (Succeeds) <-- Breakpoint --> UserProcessParallelTask(Target: 1, Opcode: INQUIRY) (Never happens) Through log comparison, we have confirmed that the DEXT's response to the TUR command for Target 1 is identical to the successful KEXT's response. We have tried creating only Target 1 (skipping Target 0 entirely), but the behavior is exactly the same -> the probe still stalls after the TUR. We initially suspected a race condition caused by consecutive calls to AsyncCreateTargetForID(). We attempted several methods to ensure that targets are created sequentially, such as trying to build a "creation chain" using OSAction completion handlers. However, these attempts were unsuccessful due to various compilation errors and API misunderstandings. In any case, this "race condition" theory was ultimately disproven by our experiment where creating only Target 1 still resulted in failure. We would like to ask two questions: Is our inability to have a Target ID greater than 0 fully probed by macOS a bug in our own code, or could there be another reason we are unaware of? If we do indeed need a "one-after-another" creation mechanism for AsyncCreateTargetForID, what is the correct way to implement a "chained creation" using OSAction completion handlers in DriverKit? Thank you for any help or guidance. Best Regards, Charles

I'm having trouble configuring the "IOPCIPrimaryMatch" entitlement. I'm currently developing using "sign to run locally" and have been able to confirm the expected behavior. I was considering signing with "Developer ID Application" for future distribution to customers, but after finding the following forum, I'm now aiming to sign with "Apple Development." https://developer.apple.com/forums/thread/743021 I'm currently having trouble with the IOPCIPrimaryMatch value. The "signing certificate" status in Xcode changes depending on the value, as follows: Successful if the value is as follows: IOPCIPrimaryMatch 0xFFFFFFFF&0x00161916 An error occurs if the value is as follows: IOPCIPrimaryMatch 0xFFFFFFFF&0x00161916 So I tried building and installing using "0xFFFFFFFF&0x00161916", but this time the driver was not assigned to the PCI device. By the way, when I used "sign to run locally", both the installation and assignment were successful with the following: IOPCIPrimaryMatch 0xFFFFFFFF&0x00161916 Could you please tell me the correct way to write this?

Hello everyone, We are in the process of migrating a high-performance storage KEXT to DriverKit. During our initial validation phase, we noticed a performance gap between the DEXT and the KEXT, which prompted us to try and optimize our I/O handling process. Background and Motivation: Our test hardware is a RAID 0 array of two HDDs. According to AJA System Test, our legacy KEXT achieves a write speed of about 645 MB/s on this hardware, whereas the new DEXT reaches about 565 MB/s. We suspect the primary reason for this performance gap might be that the DEXT, by default, uses a serial work-loop to submit I/O commands, which fails to fully leverage the parallelism of the hardware array. Therefore, to eliminate this bottleneck and improve performance, we configured a dedicated parallel dispatch queue (MyParallelIOQueue) for the UserProcessParallelTask method. However, during our implementation attempt, we encountered a critical issue that caused a system-wide crash. The Operation Causing the Panic: We configured MyParallelIOQueue using the following combination of methods: In the .iig file: We appended the QUEUENAME(MyParallelIOQueue) macro after the override keyword of the UserProcessParallelTask method declaration. In the .cpp file: We manually created a queue with the same name by calling the IODispatchQueue::Create() function within our UserInitializeController method. The Result: This results in a macOS kernel panic during the DEXT loading process, forcing the user to perform a hard reboot. After the reboot, checking with the systemextensionsctl list command reveals the DEXT's status as [activated waiting for user], which indicates that it encountered an unrecoverable, fatal error during its initialization. Key Code Snippets to Reproduce the Panic: In .iig file - this was our exact implementation: class DRV_MAIN_CLASS_NAME: public IOUserSCSIParallelInterfaceController { public: virtual kern_return_t UserProcessParallelTask(...) override QUEUENAME(MyParallelIOQueue); }; In .h file: struct DRV_MAIN_CLASS_NAME_IVars { // ... IODispatchQueue* MyParallelIOQueue; }; In UserInitializeController implementation: kern_return_t IMPL(DRV_MAIN_CLASS_NAME, UserInitializeController) { // ... // We also included code to manually create the queue. kern_return_t ret = IODispatchQueue::Create("MyParallelIOQueue", kIODispatchQueueReentrant, 0, &ivars->MyParallelIOQueue); if (ret != kIOReturnSuccess) { // ... error handling ... } // ... return kIOReturnSuccess; } Our Question: What is the officially recommended and most stable method for configuring UserProcessParallelTask_Impl() to use a parallel I/O queue? Clarifying this is crucial for all developers pursuing high-performance storage solutions with DriverKit. Any explanation or guidance would be greatly appreciated. Best Regards, Charles

Hi everyone, We are in the process of migrating a legacy KEXT for our external multi-disk RAID enclosure to the modern DriverKit framework. During the performance validation of our KEXT, we observed a large and consistent maximum throughput difference between Intel-based Macs and Apple Silicon-based Macs. We would like to share our findings and hope to discuss with others in the community to see if you have had similar experiences that could confirm or correct our understanding. The Observation: A Consistent Performance Gap When using the exact same external RAID hardware (an 8-HDD RAID 5 array), driven by our mature KEXT, we see the following results in high-throughput benchmarks (AJA System Test, large sequential writes): On a 2020 Intel-based Mac: We consistently achieve a throughput of ~2500 MB/s. On modern M-series Macs (from M1 to M4): The throughput is consistently capped at ~1500 MB/s. This performance difference of nearly 40% is significant and is present across the entire Apple Silicon product line. Our Hypothesis: A Shift in Architectural Design Philosophy Since the KEXT and external hardware are identical in both tests, we believe this performance difference is not a bug but a fundamental platform architecture distinction. Our hypothesis is as follows: 1. The Intel Mac Era ("Dedicated Throughput") The Intel-based Macs we tested use a dedicated, discrete Intel Thunderbolt controller chip. This chip has its own dedicated PCIe lanes and resources, and its design appears to be singularly focused on maximizing raw, sustained data throughput for external peripherals. 2. The Apple Silicon Era ("Integrated Efficiency") In contrast, M-series Macs use a deeply integrated I/O controller inside the SoC. This controller must share resources, such as the total unified memory bandwidth and the chip's overall power budget, with all other functional units (CPU, GPU, etc.). We speculate that the design priority for this integrated I/O controller has shifted from "maximizing single-task raw throughput" to "maximizing overall system efficiency, multi-task responsiveness, and low latency." As a result, in a pure, single-task storage benchmark, its performance ceiling may be lower than that of the older, dedicated-chip architecture. Our Question to the Community: Is our understanding correct? Have other developers of high-performance storage drivers or peripherals also observed a similar performance ceiling for external storage on Apple Silicon Macs, when compared to high-end Intel Macs? We believe that understanding this as a deliberate architectural trade-off is crucial for setting realistic performance targets for our DEXT. Our current goal has been adjusted to have our DEXT match the KEXT's ~1500 MB/s on the M-series platform. Any insights, confirmations, or corrections from the community or Apple engineers would be greatly appreciated. Thank you very much! Charles

Hello everyone, We are migrating our KEXT for a Thunderbolt storage device to a DEXT based on IOUserSCSIParallelInterfaceController. We've run into a fundamental issue where the driver's behavior splits based on the I/O source: high-level I/O from the file system (e.g., Finder, cp) is mostly functional (with a minor ls -al sorting issue for Traditional Chinese filenames), while low-level I/O directly to the block device (e.g., diskutil) fails or acts unreliably. Basic read/write with dd appears to be mostly functional. We suspect that our DEXT is failing to correctly register its full device "personality" with the I/O Kit framework, unlike its KEXT counterpart. As a result, low-level I/O requests with special attributes (like cache synchronization) sent by diskutil are not being handled correctly by the IOUserSCSIParallelInterfaceController framework of our DEXT. Actions Performed & Relevant Logs 1. Discrepancy: diskutil info Shows Different Device Identities for DEXT vs. KEXT For the exact same hardware, the KEXT and DEXT are identified by the system as two different protocols. KEXT Environment: Device Identifier: disk5 Protocol: Fibre Channel Interface ... Disk Size: 66.0 TB Device Block Size: 512 Bytes DEXT Environment: Device Identifier: disk5 Protocol: SCSI SCSI Domain ID: 2 SCSI Target ID: 0 ... Disk Size: 66.0 TB Device Block Size: 512 Bytes 2. Divergent I/O Behavior: Partial Success with Finder/cp vs. Failure with diskutil High-Level I/O (Partially Successful): In the DEXT environment, if we operate on an existing volume (e.g., /Volumes/MyVolume), file copy operations using Finder or cp succeed. Furthermore, the logs we've placed in our single I/O entry point, UserProcessParallelTask_Impl, are triggered. Side Effect: However, running ls -al on such a volume shows an incorrect sorting order for files with Traditional Chinese names (they appear before . and ..). Low-Level I/O (Contradictory Behavior): In the DEXT environment, when we operate directly on the raw block device (/dev/disk5): diskutil partitionDisk ... -> Fails 100% of the time with the error: Error: -69825: Wiping volume data to prevent future accidental probing failed. dd command -> Basic read/write operations appear to work correctly (a write can be immediately followed by a read within the same DEXT session, and the data is correct). 3. Evidence of Cache Synchronization Failure (Non-deterministic Behavior) The success of the dd command is not deterministic. Cross-environment tests prove that its write operations are unreliable: First Test: In the DEXT environment, write a file with random data to /dev/disk5 using dd. Reboot into the KEXT environment. Read the data back from /dev/disk5 using dd. The result is a file filled with all zeros. Conclusion: The write operation only went to the hardware cache, and the data was lost upon reboot. Second Test: In the DEXT environment, write the same random file to /dev/disk5 using dd. Key Variable: Immediately after, still within the DEXT environment, read the data back once for verification. The content is correct! Reboot into the KEXT environment. Read the data back from /dev/disk5. This time, the content is correct! Conclusion: The additional read operation in the second test unintentionally triggered a hardware cache flush. This proves that the dd (in our DEXT) write operation by itself does not guarantee synchronization, making its behavior unreliable. Our Problem Based on the observations above, we have the conclusion: High-Level Path (triggered by Finder/cp): When an I/O request originates from the high-level file system, the framework seems to enter a fully-featured mode. In this mode, all SCSI commands, including READ/WRITE, INQUIRY, and SYNCHRONIZE CACHE, are correctly packaged and dispatched to our UserProcessParallelTask_Impl entry point. Therefore, Finder operations are mostly functional. Low-Level Path (triggered by dd/diskutil): When an I/O request originates from the low-level raw block device layer: The most basic READ/WRITE commands can be dispatched (which is why dd appears to work). However, critical management commands, such as INQUIRY and SYNCHRONIZE CACHE, are not being correctly dispatched or handled. This leads to the incorrect device identification in diskutil info and the failure of diskutil partitionDisk due to its inability to confirm cache synchronization. We would greatly appreciate any guidance, suggestions, or insights on how to resolve this discrepancy. Specifically, what is the recommended approach within DriverKit to ensure that a DEXT based on IOUserSCSIParallelInterfaceController can properly declare its capabilities and handle both high-level and low-level I/O requests uniformly? Thank you. Charles

We want to allocate a block of contiguous memory (≤1M) for audio ring DMA usage, but we haven't found any explicit method in the DriverKit documentation for allocating contiguous memory. I'm aware that IOBufferMemoryDescriptor::Create can be used in DriverKit to allocate memory and share it with user space. However, is the allocated memory physically contiguous? Can it guarantee that when I subsequently call PrepareForDMA in IODMACommand, there will be only one segment? Could you please help review this? Thank you!

Hi, On macOS 11 and earlier versions, we provided users with the following script to uninstall our kext driver: sudo pkgutil --only-files --files com.magewell.ProCapture | tr '\n' '\0' | xargs -n 1 -0 sudo rm -vf sudo pkgutil --only-dirs --files com.magewell.ProCapture | grep ProCapture[^/]*$ | tr '\n' '\0' | xargs -n 1 -0 sudo rm -rvf sudo pkgutil --forget com.magewell.ProCapture sudo kextcache -system-caches However, this script no longer works on macOS 13 and returns the following error: It looks like you're trying to update the system caches. As of macOS 11, the personality cache is no longer in use for keeping kext matching information up-to-date. For more information, see `man kmutil`. This indicates we can no longer use kextcache -system-caches to clear our driver cache. This creates an issue where even after installing the new dext driver, the dext driver cannot run due to the presence of the old kext driver. We've tried various methods but haven't been able to completely uninstall the old kext driver - after every new system update, the old kext reappears. The specific process is as follows: This is the sequence I followed in my latest test - Device is running macOS 13 Ventura w/ 4247 Pro Capture kext driver installed kmutil inspect | grep -i magewell - this returns references to the kext files in /Library/Extensions, which is expected because I have not yet removed the 4247 kext driver - then I ran the following combination of your removal script and my removal steps: cd / sudo rm -r /Library/Extensions/ProCaptureDriver.kext sudo rm -r /Library/Extensions/ProCaptureEvent.kext sudo rm /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache.auxkc* sudo pkgutil --only-files --files com.magewell.ProCapture | tr '\n' '\0' | xargs -n 1 -0 sudo rm -vf sudo pkgutil --only-dirs --files com.magewell.ProCapture | grep ProCapture[^/]*$ | tr '\n' '\0' | xargs -n 1 -0 sudo rm -rvf sudo pkgutil --forget com.magewell.ProCapture sudo kextcache --clear-staging sudo kcditto sudo kmutil install --update-preboot sudo shutdown -r now - After this I ran 'kmutil inspect | grep -i magewell' and got no results, which seems good but... - then I ran the upgrade to macOS 15.7 Sequoia - Afterwards I ran 'kmutil inspect | grep -i magewell' and it returned references to the old /Library/Extensions kexts again, although the files no longer exist in /Library/Extensions - I then ran my cleanup process again (slightly different for Sequoia-available commands): sudo rm /System/Volumes/Preboot/*/boot/*/System/Library/Caches/com.apple.kernelcaches/kernelcache.auxkc* sudo kextcache --clear-staging sudo kmutil rebuild sudo kcditto sudo kmutil install --update-preboot sudo shutdown -r now - Then I ran 'kmutil inspect | grep -i magewell' and got no results again - As a next test I ran a minor update to macOS 15.7.1, then ran 'kmutil inspect | grep -i magewell' and the references to the old kexts came back again We have indeed identified a solution to address this issue: kmutil trigger-panic-medic --volume-root /Volumes/<YourVolumeName> However, this method requires booting into Recovery Mode, which is unacceptable for many of our customers. Especially for those who need bulk remote management, having personnel physically operate each machine one by one is simply not feasible. Therefore, is there a method to completely uninstall the kext driver while in normal mode? Thank you!

The device I am trying to develop a firmware updater for is an NVMe drive with a USB4 interface. It can connect in USB4 mode (tunneled NVMe), in USB 3 mode or in USB 2 mode. In USB 2 and USB 3 mode, the device descriptor shows one interface with two alternates. Alternate 0 uses the bulk-only protocol, with one IN and one OUT pipe. Alternate 1 uses the UAS protocol, with two IN and two OUT pipes. I use identical code in my driver to send custom CDBs. I can see using IORegistryExplorer that in USB 2 mode, macOS chooses alternate 0, the bulk-only protocol. My custom CDBs and their accompanying data pay loads are put on the bus, more or less as expected. In USB 3 mode, macOS chooses alternate 1, the UAS protocol. My custom CDB is put on the bus, but no payload data is transferred. Is this expected behavior? If so, is there a way to force the OS to choose alternate 0 even when on USB 3, perhaps with another dext? I'll file a bug about this when Feedback Assistant lets me.

Hello everyone, I am migrating a KEXT for a SCSI PCI RAID controller (LSI 3108 RoC) to DriverKit (DEXT). While the DEXT loads successfully, I'm facing a DMA issue: an INQUIRY command results in a 0-byte disk because the data buffer received by the DEXT is all zeros, despite our firmware logs confirming that the correct data was prepared and sent. We have gathered detailed forensic evidence and would appreciate any insights from the community. Detailed Trace of a Failing INQUIRY Command: 1, DEXT Dispatches the Command: Our UserProcessParallelTask implementation correctly receives the INQUIRY task. Logs show the requested transfer size is 6 bytes, and the DEXT obtains the IOVA (0x801c0000) to pass to the hardware. DEXT Log: [UserProcessParallelTask_Impl] --- FORENSIC ANALYSIS --- [UserProcessParallelTask_Impl] fBufferIOVMAddr = 0x801c0000 [UserProcessParallelTask_Impl] fRequestedTransferCount = 6 2, Firmware Receives IOVA and Prepares Correct Data: A probe in our firmware confirms that the hardware successfully received the correct IOVA and the 6-byte length requirement. The firmware then prepares the correct 6-byte INQUIRY response in its internal staging buffer. Firmware Logs: -- [FIRMWARE PROBE: INCOMING DMA DUMP] -- Host IOVA (High:Low) = 0x00000000801c0000 DataLength in Header = 6 (0x6) --- [Firmware Outgoing Data Dump from go_inquiry] --- Source Address: 0x228BB800, Length: 6 bytes 0x0000: 00 00 05 12 1F 00 3, Hardware Reports a Successful Transfer, but Data is Lost: After the firmware initiates the DMA write to the Host IOVA, the hardware reports a successful transfer of 6 bytes back to our DEXT. DEXT Completion Log: [AME_Host_Normal_Handler_SCSI_Request] [TaskID: 200] COMPLETING... [AME_Host_Normal_Handler_SCSI_Request] Hardware Transferred = 6 bytes [AME_Host_Normal_Handler_SCSI_Request] - ReplyStatus = SUCCESS (0x0) [AME_Host_Normal_Handler_SCSI_Request] - SCSIStatus = SUCCESS (0x0) The Core Contradiction: Despite the firmware preparing the correct data and the hardware reporting a successful DMA transfer, the fDataBuffer in our DEXT remains filled with zeros. The 6 bytes of data are lost somewhere between the PCIe bus and host memory. This "data-in-firmware, zeros-in-DEXT" phenomenon leads us to believe the issue lies in memory address translation or a system security policy, as our legacy KEXT works perfectly on the same hardware. Compared to a KEXT, are there any known, stricter IOMMU/security policies for a DEXT that could cause this kind of "silent write failure" (even with a correct IOVA)? Alternatively, what is the correct and complete expected workflow in DriverKit for preparing an IOMemoryDescriptor* fDataBuffer (received in UserProcessParallelTask) for a PCI hardware device to use as a DMA write target? Any official documentation, examples, or advice on the IOMemoryDescriptor to PCI Bus Address workflow would be immensely helpful. Thank you. Charles

Hello everyone, I've encountered a very strange and persistent logging issue with my DriverKit DEXT and would appreciate any insights from the community. [Problem Summary] My DriverKit DEXT, along with its companion Swift app, is functionally working perfectly. I can repeatedly call methods in the DEXT from the app (e.g., a Ping-Pong test and a StaticProcessInbandTask call) and receive the correct response every time. However, the os_log messages within my IOUserClient subclass are only successfully recorded for the very first set of interactions. After that, all subsequent logs are completely missing. What's even stranger is that all successfully recorded logs are attributed to the kernel: process, even for purely user-space methods like ExternalMethod. [Development Environment] macOS: 15.7.1 Xcode: 16.4 Hardware: MacBook Pro M1 DEXT Logging Macro (Log.h): #include <os/log.h> #define Log(fmt, ...) \ do { \ os_log(OS_LOG_DEFAULT, "[%{public}s] " fmt, __FUNCTION__, ##__VA_ARGS__); \ } while (0) [Steps to Reproduce & Observed Behavior] The DEXT is successfully loaded via the companion app. I click the "Ping-Pong" button, then the "Process InBand" button in the app. The app's UI log correctly shows that the request was sent and a successful response was received from the DEXT. I repeat step 2 multiple times. Each interaction works flawlessly from the app's perspective. I then use the log show command to export the logs from this period, for example: log show --last 5m | grep "com.accusys.Acxxx.driver" > dext_logs.txt Observed Result (Log Content): In the dext_logs.txt file, I can only see the logs from the very first Ping-Pong and the very first Process InBand call. All subsequent, successful operations leave no trace in the logs. kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // { --- kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // --- } kernel: (com.accusys.Acxxx.driver.dext) [StaticPingPong] // { --- kernel: (com.accusys.Acxxx.driver.dext) [StaticPingPong] // --- } kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // { --- kernel: (com.accusys.Acxxx.driver.dext) [ExternalMethod] // --- } kernel: (com.accusys.Acxxx.driver.dext) [StaticProcessInbandTask] // { --- kernel: (com.accusys.Acxxx.driver.dext) [StaticProcessInbandTask] // --- } <--- END OF FILE (No new logs appear after this point) ---> [Core Questions] Why are logs in IOUserClient subclass only recorded once? Given the DEXT is clearly still running and processing requests, why would os_log calls only succeed in writing to the system log database on the first interaction? Why are all logs attributed to the kernel? Why would logs from 100% user-space code like ExternalMethod and StaticPingPong be attributed to the kernel process? [Solutions Attempted That Did Not Work] I have verified with ps aux that the DEXT process (com.accusys.Acxxx.driver) is running continuously in the background and has not crashed. Attempted to force-restart the logging service with sudo killall logd, but the issue persists. Performed the most thorough reset possible using systemextensionsctl reset followed by a full reboot, then reinstalled the DEXT. The issue remains exactly the same. Thank you for any possible help or suggestions Best, Charles

Hello everyone, I am migrating a legacy KEXT to a DriverKit (DEXT) architecture. While the DEXT itself is working correctly, I am completely blocked by a code signing issue when trying to establish the UserClient connection from our SwiftUI management app. Project Goal & Status: Our DEXT (com.accusys.Acxxx.driver) activates successfully (systemextensionsctl list confirms [activated enabled]). The core functionality is working (diskutil list shows the corresponding disk device node). The Core Problem: The userclient-access Signing Error To allow the app to connect to the DEXT, the com.apple.developer.driverkit.userclient-access entitlement is required in the app's .entitlements file. However, as soon as this entitlement is added, the build fails. Both automatic and manual signing fail with the same error: `Provisioning profile ... doesn't match the entitlements file's value for the ... userclient-access entitlement.` This build failure prevents the generation of an .app bundle, making it impossible to inspect the final entitlements with codesign. What We've Confirmed: The necessary capabilities (like DriverKit Communicates with Drivers) are visible and enabled for our App ID on the developer portal. The issue persists on a clean system state and on the latest macOS Sequoia 15.7.1. Our Research and Hypothesis: We have reviewed the official documentation "Diagnosing issues with entitlements" (TN3125). According to the documentation, a "doesn't match" error implies a discrepancy between the entitlements file and the provisioning profile. Given that we have tried both automatic and manual profiles (after enabling the capability online), our hypothesis is that the provisioning profile generation process on Apple's backend is not correctly including the approved userclient-access entitlement into the profile file itself. The build fails because Xcode correctly detects this discrepancy. Our Questions: Did we misunderstand a step in the process, or is the issue not with the entitlement request at all? Alternatively, are there any other modifications we can make to successfully connect our App to the DEXT and trigger NewUserClient? Thank you for any guidance.

We've developed a PCIDriverKit driver for the capture card on macOS and have identified an issue: CreateMemoryDescriptorFromClient can only read data from the user space to the driver, but cannot write data back to the user. typedef struct _MWCAP_EDID_DATA { uint64_t size; uint64_t uaddr; } MWCAP_EDID_DATA; // App size_t xxx::GetEdid(void *buff, size_t size) { MWCAP_EDID_DATA edid; edid.size = size; edid.uaddr = (uint64_t)buff; kr = IOConnectCallStructMethod( connect, kUserGetEdid, &edid, sizeof(MWCAP_EDID_DATA), NULL, NULL ); // kr is 0. But However, the data in the buffer remains unchanged; // it does not reflect the EDID copied from the DEXT. return size; } // Driver MWCAP_EDID_DATA *edid = (MWCAP_EDID_DATA *)input; IOMemoryDescriptor *user_buf_mem = NULL; IOAddressSegment segment; segment.address = edid->uaddr; segment.length = edid->size; // We have verified that the values in edid->uaddr and edid->size are consistent with what was set by the application. ret = CreateMemoryDescriptorFromClient(kIOMemoryDirectionOutIn, 1, &segment, &user_buf_mem); if (ret != kIOReturnSuccess) { os_log(OS_LOG_DEFAULT, "Failed to create memdesc with error: 0x%08x", ret); break; } IOMemoryMap* user_buf_map = nullptr; ret = user_buf_mem->CreateMapping(0, 0, 0, 0, 0, &user_buf_map); if (ret != kIOReturnSuccess) { os_log(OS_LOG_DEFAULT, "Failed to create mapping with error: 0x%08x", ret); OSSafeReleaseNULL(user_buf_mem); break; } // ... fill the user_buf_map with edid data ... // For example: // memcpy(user_buf_map->GetAddress(), source_edid_data, edid->size); // At this point we have also verified the data in user_buf_map->GetAddress(), which matches our expectations. OSSafeReleaseNULL(user_buf_map); OSSafeReleaseNULL(user_buf_mem); Please help take a look, thank you!

While developing our driver, we've noticed that the *.ips report that contains the stacktrace of the crash is not always generated. I'm wondering why this report may not get generated, or if there's anything specific to do to guarantee it gets generated.

Hi, We are using the AX88772C as a USB->Ethernet bridge in a product we are developing. Due to the chip not following the NCM protocol, it is not supported by the default networking drivers on the iPhone. Initially, we intended on using DriverKit to develop a userspace driver for this device. However, we have been informed DriverKit is only available on iPad OS, not iOS. As such is the case, we have found two possible alternatives. First being IOkit, and the second being External Accessory Session (EASession). What are the limitations of each of these options? We need the ability to send and receive USB packets to Control and Bulk endpoints. Is this possible with either of the options defined above? Would either of these options require the device to be MFi certified? We have read that some APIs within IOkit require the apple device to be jailbroken. Is there a list of features that can be used without a jailbroken device? Documentation on these 2 options is limited, so any official documentation would be great. Thanks!

Hi Apple, We are working on a general USB device management solution on macOS for enterprise security. Our goal is to enforce policy-based restrictions on USB devices, such as: For USB storage devices: block mount, read, or write access. For other peripherals (e.g., USB headsets or microphones, raspberry pi, etc): block usage entirely. We know in past, kernel extension would be the way to go, but as kext has been deprecated. And DriverKit is the new advertised framework. At first, DriverKit looked like the right direction. However, after reviewing the documentation more closely, we noticed that using DriverKit for USB requires specific entitlements: DriverKit USB Transport – VendorID DriverKit USB Transport – VendorID and ProductID This raises a challenge: if our solution is meant to cover all types of USB devices, we would theoretically need entitlements for every VendorID/ProductID in existence. My questions are: Is DriverKit actually the right framework for this kind of general-purpose USB device control? If not, what framework or mechanism should we be looking at for enforcing these kinds of policies? We also developed an Endpoint Security product, but so far we haven’t found a relevant Endpoint Security event type that would allow us to achieve this. Any guidance on the correct technical approach would be much appreciated. Thanks in advance for your help.

Hi, We were planning on using DriverKit to develop a USB Driver on IOS for iPhone. Within the DriverKit website, it say 'IOS16.0+' which lead us to believe it was compatible with iPhones running IOS16.0+. However, it appears DriverKit is only available for iPads running iPadOS, and computers running macOS. Are there any alternatives that would allow us to create a device specific USB driver for an iPhone running IOS?

I am having similar problems to this guy on Stack Overflow over a year ago: https://stackoverflow.com/questions/77627852/functions-of-iouserscsiperipheraldevicetype00-class-in-scsiperipheralsdriverkit There are also a few questions on this forum about this object, none of which have answers. I can get my driver to match and instantiate, but nobody calls my UserDetermineDeviceCharacteristics (which does nothing, just returns kIOReturnSuccess) I can attempt to call UserSuspendServices(), UserResumeServices() or UserReportMediumBlockSize() and all of them return kIOReturnUnsupported. It doesn't matter if I've unmounted the disk or not. Is the custom driver supposed to be instantiated beside the kernel's IOSCSIPeripheralDeviceType00, or should it replace it? What should its IOProviderClass be? What should its IOClass be - IOUserService, or something else? see FB19678139 and FB19677920

Hi guys! OK, reaching out for some help here. I am having all kinds of trouble with OSDeclareDefaultStructors. I have seriously been at this for nearly a week now and have come to the conclusion that I need to reach out for help from people that are more experience using Xcode. I believe entirely that my issue is just that I can't for whatever reason see how to set up includes and libraries and things like that. I have this line: OSDeclareDefaultStructors(NukeVirtualGamepad) No matter what I do, Xcode will not recognize OSDeclareDefaultStructors. The project builds a DriverKit &gt; Driver extension. I have literally tried absolutely everything with this. I am at a loss for words. I even set up a new blank project and it still will not recognize OSDeclareDefaultStructors. I did a lot of research and it looks like expo needs OSDeclareDefaultStructors in order for the extension to build with a binary in it instead of being just a codeless extension. Here is the code with the issue: #pragma once #include &lt;DriverKit/OSMetaClass.h&gt; #include &lt;HIDDriverKit/IOUserHIDDevice.h&gt; #include &lt;DriverKit/OSData.h&gt; class NukeVirtualGamepad : public IOUserHIDDevice { OSDeclareDefaultStructors(NukeVirtualGamepad) // The problem is right here! This line! public: // Keep it minimal; no 'override' keywords since the .h types may not mark them virtual bool init(); void free(); kern_return_t Start(IOService* provider); void Stop (IOService* provider); OSData* newReportDescriptor(); // (Optional) helper you’ll use later to inject input matching your report kern_return_t PostInput(uint16_t buttons, int8_t x, int8_t y); }; I do have to mention to everyone that I am still very new with Xcode. So there is a ton that I don't know yet or might be misunderstanding. Has anyone seen this before? Thank you in advance.

I’m creating my first DriverKit extension and I ran into an entitlement issue when trying to load my driver. Error 0x0 8397 7 taskgated-helper: (ConfigurationProfiles) [com.apple.ManagedClient:ProvisioningProfiles] App.Dext: Unsatisfied entitlements: com.apple.developer.driverkit.transport.usb I have already registered the entitlement com.apple.developer.driverkit.transport.usb with my vendor ID in the Apple Developer portal. However, when I download the provisioning profile, it doesn’t include the idVendor value. Screenshot from the developer portal (provisioning profile without idVendor) ? <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <integer>1356</integer> </dict> </array> -Is this error caused by me registering the vendor ID incorrectly? -Or is there an issue with how the entitlement is reflected in the provisioning profile? Any guidance would be appreciated.