dext | 🔍 A smart launcher Powered by JavaScript | BPM library

The problem was caused by an IOUserNetworkPacketBufferPool bug. My bufferSize was set to 1600 except this value was ignored and replaced with 2048. The IOUserNetworkPackets acted as though the bufferSize was 1600 and so they gave an invalid offset.

Creating the buffer pool and mapping it:

I haven't yet implemented an ethernet dext myself, but based on my experience with using DriverKit for other types of drivers and knowing its design goals, I have an idea what the solution might be.

First off, let's clarify: you're implementing either a virtual ethernet device, or you're building a driver for hardware that unites multiple independent ports in one physical device. In the former case (I'm guessing this is what you're doing based on your IOUserClient comment), your driver will be matching IOUserResources and you create the ethernet driver instance when you receive the corresponding message from your user space component.

Now, DriverKit design: DriverKit is built around a goal of keeping the driver instance for each device in its own separate process. Sort of circling back to the microkernel idea. Specifically, this means that multiple devices that use the same driver will each create an independent instance of that driver in its own process. This very likely means that NetworkingDriverKit was never designed to support more than one instance of IOUserNetworkEthernet, because they are seen as separate devices. Hence the crashes.

OK, what do we do about it? Use DriverKit the way it was intended. Put each virtual ethernet adapter in its own driver instance. This gets a bit tricky. I think this should work:

• Your dext has a "control" instance. This is the thing that matches IOUserResources. It's a simple IOService class which listens for the signal (presumably IOUserClient) to create or destroy a virtual ethernet device. When creating a virtual ethernet device, you need that to run in its own driver instance though. (For an actual device with multiple ports, this would match the USB/PCI device nub, manage bus communication with the device, and enumerate the ports.)
• Instead of creating an instance of a IOUserNetworkEthernet subclass, create an instance of a "nub" class and attach it to your central control class instance. Call RegisterService() in its startup code, so it's considered for IOKit matching.
• Set up a second IOKit matching dictionary in your Info.plist, which matches your new "nub" object. Here, use your IOUserNetworkEthernet-derived class to "drive" the nub. Once the virtual ethernet device is ready to use, call RegisterEthernetInterface().

2 extra things to note:

1. The virtual device will run in a separate process from the control object, so they can only communicate via DriverKit inter-process calls, i.e. user clients. Hopefully, they don't really need to communicate much though, and the control client can pass all the information required via properties on the nub. If you're implementing support for multi-port hardware, you probably won't be able to avoid this part though.
2. Your user space component (app, daemon) will need to open a new communication channel with the virtual device, so you'll probably need to implement user client support there too.

I'm not sure how you'd go about shutting down an individual virtual ethernet device, you could try calling Terminate() on either it or the nub it's matched on and see what happens.

Turns out IOPCIDevice::_CopyDeviceMemoryWithIndex was indeed the function needed to implement this (but the fact that it's private is still an inconvenient).

Bellow is some sample code showing how this could be implemented (the code uses MyDriver for the driver class name and MyDriverUserClient for the user client).

Relevant sections from MyDriver.cpp implementation:

It's not quite the same question as yours, but in my answer to it I go into some detail on memory descriptors in DriverKit extensions.

Basically, in DriverKit you can only access user space memory that was explicitly provided as a buffer; you can't interpret arbitrary data as pointers in the user process's address space and create memory descriptors for them.

The only way to create memory descriptors for user space buffers that I'm aware of is via "struct" arguments to IOUserClient external methods, i.e. when the user process passes them to the IOConnectCallMethod* family of functions as either an input or output "struct". If the buffer is larger than 4096 bytes, it'll show up in the dext as an IOMemoryDescriptor, and you can perform the usual DMA operations with it.

Typically, you'll want to do this in combination with async external methods, which lets you implement sensible buffer lifetime semantics, but your dext can technically hold on to user space supplied memory descriptors past the return of a synchronous external method, or past the async completion of an asynchronous one.

I don't have a 100% answer as to why it's going wrong in your case. To load a dext on an unmodified system, you definitely need the following when codesigning your dext:

• Sign with a 'Developer ID Application' certificate identity and be notarised, or signed with an 'Apple Developer' certificate
• Embedded code signing entitlements including the generic DriverKit entitlement, any family-specific entitlements, and entitlements regarding user client access if necessary.
• A provisioning profile from Apple which matches:
  1. The code signing entitlements you are embedding in the dext.
  2. The type and specific instance of the code signing identity you are using to sign the dext.
  3. The Application & Bundle ID of the dext.
  4. If using an Apple Developer signing identity, the hardware IDs of the Macs on which you will be testing the dext.

For local testing, you can try the following things to temporarily work around code signing issues:

• Disabling System Integrity Protection (SIP). For purposes of DriverKit extensions, this disables some codesigning checks.
• Disabling DriverKit-specific entitlements checks. This turns off checking for a lot of family-specific entitlements. To disable the checks, set flag 0x8000 in the dk kernel boot argument, which is a bitfield. Note that unless you set flag 0x1, DriverKit will be entirely disabled. So use dk=0x8001 to disable DriverKit entitlement checks.
• Disabling AMFI checks. AMFI will normally kill your process if you try to claim entitlements which need to be enabled in a provisioning profile. You can disable AMFI with the amfi_get_out_of_my_way=1 kernel boot argument.

Obviously, you only have limited control over the provisioning profile, as the entitlements in it must be approved by Apple. (For this reason, if you're planning to ship your dext publicly, I generally recommend you try to work out what entitlements you might need before starting full development on the dext, and request them from Apple. The process can take months.) So while it would be interesting to know the exact minimum combination of workarounds required when you don't have these profiles, I haven't exhaustively tested this out yet. I realise this doesn't help much with getting your dext as close to shipping as possible while still waiting for Apple to grant missing entitlements. Hopefully one of these days I can systematically explore and document all of this.

On macOS 11, if one of Apple's kexts matches your device, and their driver is in the "boot" or "sys" collections (see man kmutil), which it normally will be, then their driver will win matching against yours, even if yours has a higher probe score.

On macOS 10.15, it should depend on whether or not their kext is in the prelinked kernel/kext cache. Third party kexts can also be included here so it's a little more democratic at least. Dexts can't be in the kextcache though.

I've filed an Apple DTS TSI about this issue and they've acknowledged it as a bug. I strongly recommend you file it as a bug as well to increase chances of it being fixed.

You should be able to work around it in a rather ugly way by explicitly force resetting the device from a user space daemon if your driver didn't manage to grab it. This will cause it to be re-enumerated by the USB subsystem, and for I/O Kit matching to be repeated, at which point your dext hopefully manages to win!

The com.apple.developer.driverkit.userclient-access key should indeed be an array of strings with the bundle IDs listed. This is what I've got in the .entitlements file for the app in my "demo" DriverKit project which I use for prototyping things:

I was banging my head hard against getting the same thing to work. In the end I managed to get a working DEXT that disables the Apple HID driver for specific vendor ID/product ID combinations. We have obtained the DriverKit entitlement for our vendor ID.

1. It looks like the default subclass of IOService is OK for USB - that is the same as the IOClass from the KEXT. Is that true?

This worked for me. I tried removing the .iig and .cpp files completely, but unlike KEXTs, it seems that there needs to be some code compiled in order for signing to work properly. So I ended up with just an empty subclass of IOService.

1. Is IOUSBHostInterface in DEXT-world equivalent to IOUSBInterface in KEXT-world?

I believe so. I used IOUSBHostInterface and we had IOUSBInterface in our KEXT.

1. Is IOUSBHostDevice equivalent to IOUSBDevice?

I don't know, but I believe so.

1. Do I need to do anything to the .cpp or .iig for codeless DEXT? Isn't most of my work to be done in the plist and entitlements files?

I did not need to change anything in the .cpp and .iig files. You might want to delete the os_log(OS_LOG_DEFAULT, "Hello World"); line in the .cpp file before you release it. But while debugging, it was useful for me to tell whether the DEXT was actually loading or not. You can run log stream --source | grep 'HELLO' in a terminal to look for the log.

1. Do I need the USBDriverKit.framework in my Frameworks and Libraries of MyUsbDriver target?

My DEXT links against DriverKit.framework. I don't know if it's needed or not.

1. Where can I find a decent example of how to complete this migration?

Maybe these can help:

• https://github.com/stuartlynne/USBApp-updated
• Migrating from codeless KEXT to DEXT. Usb interfaces disappeared
• Performance issue after migrating from codeless KEXT to DEXT

During development of a DriverKit extension (dext), do the following:

• Disable system integrity protection (SIP): https://apple.stackexchange.com/a/208481/21491. (Reboot in recovery mode, run csrutil disable). Remember to enable it again!

• Enable system extension development mode by running systemextensionsctl developer on

• Make sure you don't have your old codeless KEXT installed. (Delete it from /Library/Extensions and/or /System/Library/Extensions. Make sure to reboot afterwards)

• You might need a manual provisioning profile that contains the DriverKit entitlements. I think my problem was that I got the DriverKit entitlement on an enterprise developer team instead of a team for public development.

• The app that loads the extension needs the "System Extension" entitlement, but does not need a manual provisining profile.

• Be ware of a stupid bug in System Preferences. You need to consent to loading the dext every time it gets loaded. However, if the "Security & Privacy" pane is already open, it will not show the button to give the consent. You need to restart System Preferences for it to show up. I've been using the command pkill -9 "System Preferences"; open /System/Library/PreferencePanes/Security.prefPane from Terminal generously to workaround this.

• You can use systemextensionsctl to uninstall the dext or reset the system state. However, this does not actually change the driver matching, so you need to reboot. Generously. I used this Terminal command because I'm lazy: osascript -e 'tell app "System Events" to restart'.

• You can use ioreg to check whether devices are being matched to the extension or not: ioreg -lirc IOUSBHostInterface.

• The key to getting the extension to work is to set the IOProviderClass to IOUSBHostInterface instead of IOResources in the Info.plist file. (For reference, the KEXT uses IOUSBInterface which is one of the classes that Apple has deprecated)

• You might want to bump the version in Info.plist every time you make changes to your DEXT to make sure that you are actually using the correct one. (systemextensionsctl will show the version it has loaded).

After a week of vacation not thinking about work at all, I figured this problem out! I re-read information in How to set `com.apple.developer.driverkit.transport.usb` entitlement? and realized my entitlements file was not correctly formatted.

Here is my old file, created in the editor in Xcode: