Custom ethernet interface with userspace transport via DriverKit

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?

We're developing a custom Thunderbolt device and want to expose it to macOS as an ethernet interface, while owning the full network stack implementation up to and including IP, TCP and UDP — bypassing the macOS network stack for those layers. Is IOEthernetController the right DriverKit approach for this, and does it allow intercepting traffic before it reaches the macOS IP stack?

Why? What are you actually trying to do here? More specifically, what do you expect to actually be interacting with your user space component?

If you go down this route, then you're telling the system "here is a network interface you should use" and the system is absolutely going to try and use it. At that point you're going to be forced to try and find ways to keep the system "away" from the interface you just created... since the point of an network interface is to provide an generic endpoint the system can interact with.

Maybe there's a reason you want to do this, but if your ultimate goal is just to communicate with your device, then this seems like an awful lot of work to avoid using IOUserClient. Keep in mind that IOUserClient is sufficiently fast and powerful that there's always a way to do basically ANYTHING you want.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Why? What are you actually trying to do here? More specifically, what do you expect to actually be interacting with your user space component? If you go down this route, then you're telling the system "here is a network interface you should use" and the system is absolutely going to try and use it. At that point you're going to be forced to try and find ways to keep the system "away" from the interface you just created... since the point of an network interface is to provide an generic endpoint the system can interact with. Maybe there's a reason you want to do this, but if your ultimate goal is just to communicate with your device, then this seems like an awful lot of work to avoid using IOUserClient. Keep in mind that IOUserClient is sufficiently fast and powerful that there's always a way to do basically ANYTHING you want.

Sorry for the confusion. The goal is not just to communicate with the device from our app. We want to expose a network accelerator to macOS — a device that handles the full network stack from Layer 2 (Ethernet) to Layer 4 (TCP/UDP), offloading those layers from the macOS network stack entirely, similar to a SmartNIC.

In that context, what would be the right DriverKit approach to expose such a device to macOS?

Following up: would NETransparentProxyProvider be appropriate to intercept TCP/UDP flows and redirect them to a custom transport? And for traffic not covered by NETransparentProxyProvider (ICMP, ARP, etc.), would declaring the device via IOEthernetController creates conflicts with the proxy interception, or can both coexist cleanly?

Custom ethernet interface with userspace transport via DriverKit
 
 
Q