IOService::serviceMatching() or alternate in DriverKit

I am also searching for the same.
pls share if you have got any info.

Hello,

As it happens, there isn't a replacement for IOService::serviceMatching() in DriverKit.

Matching of DriverKit drivers (dexts) is handled by the contents of the DriverKit driver's info.plist and entitlements. There is no way for a DriverKit driver to programmatically (e.g., use IOService::serviceMatching()) modify the DriverKit driver's matching rules.

This doesn't mean that multiple USB DriverKit drivers (or multiple instances of the same driver) are required to support a single USB device that has multiple [sibling] interfaces (such as USB CDC ECM COMM & DATA). That's because a single USB DriverKit driver that matches against a single USB Interface class can use multiple interfaces.

In order to do this the DriverKit driver (after it's started, when the USB device discovered) needs to scan the USB device's configuration descriptor to find the other USB interface. With the caveat that the need to recognize & support USB Alternate Settings makes things a bit more complex, the driver would use CopyConfigurationDescriptor() to get a copy of the device's configuration descriptor, then use IOUSBGetNextInterfaceDescriptor to iterate through the interface descriptors (associated with that configuration descriptor) to locate an interface with the desired interface class (e.g., USB CDC ECM DATA = 0x0A).

The driver then needs to look through the interface objects that are associated with the device, find an interface that has a bInterfaceNumber that matches the bInterfaceNumber from the interface descriptor that was previously found, and then set the device to use the "alternate setting" from the interface object that was just found. At this point you'll have a *second* USB interface object to the DATA interface that driver can use, as well as the COMM interface (that resulted in the driver matching in the first place).

If you need help making this work I recommend that you submit a "Technical Support Incident" to DTS next week.

Best regards,

C.

I have the configuration descriptor parsing working and had determined that the new strategy was as you outlined above.

The KEXT being ported used a similar strategy to implement a single virtual network interface that was shared by 1 to N physical devices. I.e. instead of N network interfaces being created.

The serviceMatching() was used by the data KEXT to find the virtual network KEXT.

I have been able to load both a virtual DEXT to and USB DEXT successfully. But need to determine how they can find each other and transfer data between them.

Hello,

I am not aware of a mechanism or API that's built into builtDriverKit which can be used by a dext to search for and open a connection with an arbitrary kext.

What I recommend you look into is creating a helper app/process that opens a user client connection with the dext, as well as opens a connection with the kext, and acts as bridge between the kext and the dext.

See the "NewUserClient" description for details on how an app can open a user client connection with a dext:

"Override this method if your service supports communication though an external user client.
When an app calls IOServiceOpen to start a new service, the system calls this method on the
service passed to that function. In your implementation, call the Create method to create a new
IOUserClient object for your service and return that object in the userClient parameter."

You mentioned a "virtual networking KEXT" so I thought it'd be worthwhile to mention that a number of networking KPIs are deprecated in macOS 10.15.4. See the "Deprecated Kernel Extensions and System Extension Alternatives" article for details on which of the networking KPIs have been deprecated. Note also the statement in this article that "Kernel programming interfaces (KPIs) will be deprecated as alternatives become available, and future OS releases will no longer load kernel extensions that use deprecated KPIs by default."

If your virtual networking kext uses any of the KPIs described in the networking section of this article then you should expect that your kext will trigger a notification to the user that software (your kext) uses a deprecated KPI and that they (the user) should contact the developer for an alternative. In short, if your virtual networking kext uses any of the deprecated KPIs then I strongly recommend that you migrate to a non-kext solution as quickly as possible.

Best regards,

C.

Thanks, I was hoping to avoid having to have a helper application running. That would of course work.

I don't believe we use any of the deprecated KPI's, this will be a simple NetworkingDriverkit Driver Extension.