A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers
If you haven't already, please file a bug asking for the dev-only entitlements to be enabled on free developer accounts, and post the bug number back here. I can't promise it will happen, but it's an interesting idea that I don't think we've really considered.
Published approval criteria and timelines so projects can plan accordingly
Unfortunately, publishing truly formal criteria is much more difficult than it sounds since, in practice, it's very difficult to come up with a criteria set that EXACTLY covers every reasonable use case while also excluding every possible "unreasonable" use case... and that assumes we could even come up with every use case.
However, on this point:
Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed.
We understand that the nature of real-world hardware development means that we simply cannot expect that drivers will only be written by the formal owners of a given vendor ID. We can and do approve requests from 3rd-party vendors and, in general, we try to lean toward approving requests, not rejecting them.
However, one request we are VERY unlikely to approve is this:
A class-level or wildcard VID/PID entitlement for open-source projects with a verifiable public repository
I can't say that we'll NEVER approve a wildcard entitlement request, but we haven't approved one yet and I can't think of any scenario where we would approve such a configuration. There are many reasons for that, but the basic, technical issue is that DriverKit doesn't really implement the active matching phase that IOKit does, relying almost entirely on passive matching.
For the VAST majority of drivers, that difference is totally irrelevant— they were already matching against specific hardware, so eliminating active matching didn't really change anything. Indeed, the only real problem we've seen is from developers with VERY large hardware ranges who had shifted part of their matching logic into the active phase so that they could simplify their matching dictionary.
HOWEVER, what does create problems (and what I think you’re asking for) is drivers that want to match against a very broad hardware set (often "everything") and then reject any hardware they don't want/match/recognize. That doesn't really work in DriverKit as it both disrupts larger system functionality and can interfere with other drivers matching properly.
DEXT entitlements are issued for specific hardware because that's how we expect DriverKit to be used, and that's unlikely to change. The development-only entitlements are the only exception to this— that's partly because they're so useful but mostly because the signing model means the problems they'd create won't affect the broader user base.
Finally, I had one specific question/comment here:
My main concern is the ability of open-source projects like HoRNDIS.
How do the devices you're interacting with behave when they're attached without your driver involved? Does one of our class drivers claim them, or are they being treated as vendor-specific hardware and ignored?
If one of our drivers isn't claiming them, then I think the way I'd suggest supporting these would be:
-
A user-space process which uses the IOUSBHostFramework to find and control the device itself. This doesn't require any special entitlement/permission.
-
Your DEXT matches against IOUserResources (see this sample) so it can load without a specific target. It publishes a user client which your app uses to push data in/out of the kernel.
When your process (#1) detects one of the devices you support, it tells your dext to create a new NetworkingDriverKit endpoint, then uses the same connection to shuffle traffic between the kernel and your target device. This should let you do what you're doing now without requiring any kind of wildcard USB match.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
