I have not seen a clear answer about this:
Thus, I would like to pose: Is there any way to install a DriverKit extension locally for development and testing using a free developer account, or is development of DriverKit extensions gated behind a paid developer account?
Thank you!
Is there any way to install a DriverKit extension locally for development and testing using a free developer account, or is development of DriverKit extensions gated behind a paid developer account?
Yes, though it's not something I'd recommend. In terms of getting Xcode to build the DEXT, the standard UI no longer shows this option, but you can go into Build Settings -> Signing, and change your "Code Signing Identity" to "Sign to Run Locally". While you're there, you can also delete any entry connected to your developer account or provisioning profile reference. If you do that to both the DEXT and its containing app, Xcode should produce a build without any issue.
In terms of running that build, disabling SIP should be sufficient, but if that doesn't work, disabling AMFI will. Quinn has a forum post here describing how to do this for an ES client, but the same process would work for a DEXT.
However, I need to be clear that this isn't really something I'd recommend, especially disabling AMFI. The reason I said that AMFI "will" work is that disabling AMFI effectively disables virtually all codesign verification, allowing basically "anything" to run.
To repeat Quinn's warning:
IMPORTANT Do not disable SIP on a machine you care about. I do all of my EndpointSecurity testing in a VM, so I don’t have to disable SIP on my main work machine. If testing in a VM is insufficient, test on dedicated ‘victim’ hardware, not on your main Mac.
FYI, with the exception of the transport families (USB and PCI), I'd expect all other DriverKit families to work fine in a VM, so that’s not a bad option if you simply want to experiment.
Finally, I did have a comment here:
development of DriverKit extensions gated behind a paid developer account?
Just to clarify, the "gating" here isn't really about cost and certainly isn't specifically about restricting DriverKit. The main difference between paid and free accounts is that paid accounts can register bundle IDs, which is what’s then used to bind provisioning profiles to their specific target.
We restrict registration like this to help close out the opportunity for "mischief" and abuse that allowing unrestricted registration could create. While not a truly scarce resource, they are sometimes visible to users and there is a general expectation that an app’s bundle ID will have a connection to the app/vendor of a given app, which means most vendors would be upset/annoyed if they couldn't use "their" bundle ID for their app. The paid account requirement is the best option we've found to minimize these issues.
__
Kevin Elliott
DTS Engineer, CoreOS/Hardware
