DriverKit Port

[sgulls]

Clearly the writing is on the wall for KEXTs. We can get away with it for now by running bputil -k in 1TR for arm Macs but sooner or later KEXTs are going to go the way of 32 bit support and it's clear the original developer/maintainer cannot/will not port the code so it's up to us honestly.

I'm not that experienced with Obj-C and I've played around with the code but not everything has a drop in replacement from kernel IOKit to DriverKit so I'm in way over my head.

among some libraries/headers that I'm figuring out how to replace

In the headers file:
IOKit/usb/IOUSBHostFamily.h
IOKit/network/IOEthernetController.h & IOKit/network/IOEthernetController.h (I guess IOUserNetworkEthernet is probably the way to go but it's not quite the same)
IOKit/IOTimerEventSource.h
IOKit/IOMessage.h

in the main cpp file:
mach/kmod.h & libkern/version.h (they don't seem necessary given we're moving code away from the kernel)
IOKit/network/IOGatedOutputQueue.h

In addition, DriverKit now enumerates interfaces using a c++ class in an .iig file which handles starting, stopping and cleanup versus the kext which has everything in the .cpp body so reformatting the code will be necessary.

I only have DriverKit entitlements for a few VID/PIDs as I have to request each pair individually from Apple so I only bothered request devices I personally own. With that being said, an unsigned driver extension is vastly preferably to running in the kernel as evidenced by the kernel panics and crashes this software has wrought so far.

Anyone with any Obj-C experience willing to pitch in? I'll try learning as I go but I can't do this by myself.

[sgulls]

starting my fork here

[Belcarra]

I have a working DriverKit networking driver for RNDIS, ECM, NCM, EEM etc. I hope to make it available in the Mac store eventually. But can make it available to HoRNDIS users to use now, just finalizing the Installation application. I have the same issue with VID/PID's, I need to request each pair individually from Apple. Although I have my own VID (0x15ec) that I can allocate any PID with. If anyone wants to try it contact me with the VID/PID you need.

…

On Thu, Apr 22, 2021 at 2:02 PM sgulls ***@***.***> wrote: Clearly the writing is on the wall for KEXTs. We can get away with it for now by running bputil -k in 1TR for arm Macs but sooner or later KEXTs are going to go the way of 32 bit support and it's clear the original developer/maintainer cannot/will not port the code so it's up to us honestly. I'm not that experienced with Obj-C and I've played around with the code but not everything has a drop in replacement from kernel IOKit to DriverKit so I'm in way over my head. among some libraries/headers that I'm figuring out how to replace In the headers file: IOKit/usb/IOUSBHostFamily.h IOKit/network/IOEthernetController.h & IOKit/network/IOEthernetController.h (I guess IOUserNetworkEthernet is probably the way to go but it's not quite the same) IOKit/IOTimerEventSource.h IOKit/IOMessage.h in the main cpp file: mach/kmod.h & libkern/version.h (they don't seem necessary given we're moving code away from the kernel) IOKit/network/IOGatedOutputQueue.h In addition, DriverKit now enumerates interfaces using a c++ class in an .iig file which handles starting, stopping and cleanup versus the kext which has everything in the .cpp body so reformatting the code will be necessary. I only have DriverKit entitlements for a few VID/PIDs as I have to request each pair individually from Apple so I only bothered request devices I personally own. With that being said, an unsigned driver extension is vastly preferably to running in the kernel as evidenced by the kernel panics and crashes this software has wrought so far. Anyone with any Obj-C experience willing to pitch in? I'll try learning as I go but I can't do this by myself. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#139>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALJH5CIUKEFVZN4U3J4DSDTKCFFPANCNFSM43NLL5EQ> .

-- Belcarra Embedded USB Software Stuart_Lynne ***@***.***> 604-461-7532 Alternates: 604-283-7475 and 604-518-1749(cell) http://usblan.belcarra.com http://www.belcarra.com

[jwise]

Here's a dumb question: can you use DriverKit for the network portion, and libusb for the USB portion? For a while I was thinking that the future of HoRNDIS would be tun/tap-based for network and libusb for USB.

[krjw-eyev]

@Belcarra that sounds great! When are you planning to release it?

@sgulls I have looked at your repository and have noticed that you added code for a SwiftUI App. What was your plan? How far did you come porting it to DriverKit?

[Belcarra]

On Thu, Jun 10, 2021 at 6:54 AM Konstantin Wachendorff < ***@***.***> wrote: @Belcarra <https://github.com/Belcarra> that sounds great! When are you planning to release it?

Currently getting ready to test with Monterey. Last year Apple changed the NetworkingDriverkit API in an incompatible manner that forces me to compile and build separate driverkit extensions for Catalina and BigSur. Complicated by having to actually compile the Catalina version using Xcode-11 on an Intel Mac because Xcode-12 does not have the older Catalina version of the Driverkit APIs ... Here's hoping that they have not made more changes in the Monterey APIs. There are also some runtime issues WRT to activation and deactivation of driver extensions in Catalina. So the Mac App which contains the extension needs to work differently in Catalina. I have entitlements for the Belcarra vendor ID (0x15ec) and I can generate kits that use that vendor id and any product id. So if you can set a specific vid/pid in your device I can produce test kits using that vendor id. If you own a USB Vendor ID Apple will grant entitlement for the Vendor ID (you can use any product id.) If you don't own the Vendor ID but have permission from the owner then Apple will grant entitlement for specific Vendor/Product ID pairs. I have requested USB entitlements for vendor/product ids 0x049f/0x505a and 0x0525/0xa4a2. Usually takes Apple between four and eight weeks to respond. Hopefully, they will grant them.

…

@sgulls <https://github.com/sgulls> I have looked at your repository and have noticed that you added code for a SwiftUI App. What was your plan? How far did you come porting it to DriverKit? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#139 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALJH5APDRQPRM77243BYWTTSC7Z5ANCNFSM43NLL5EQ> .

-- Belcarra Embedded USB Software Stuart_Lynne ***@***.***> 604-461-7532 Alternates: 604-283-7475 and 604-518-1749(cell) http://usblan.belcarra.com http://www.belcarra.com

[YiquanGu]

starting my fork here

Great initiative! Is your version working on M1 Big Sur?

[vricosti]

@Belcarra Any news about this ?