Develop DriverKit extensions locally with a Free Developer Account

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

Thanks for the incredibly helpful reply! I was able to successfully load the extension, but it did require disabling AMFI as you suspected.

We restrict registration like this to help close out the opportunity for "mischief" and abuse that allowing unrestricted registration could create.

Unfortunately, this does mean those with free developer accounts must defang important security protections (SIP, AMFI) in order to install our own DriverKit extensions for personal use. Would it be possible to request an exception in this case for my free developer account?

Unfortunately, this does mean those with free developer accounts must defang important security protections (SIP, AMFI) in order to install our own DriverKit extensions for personal use.

As a minor note, I think disabling SIP is sufficient, which is significantly less dangerous than disabling AMFI. My personal recommendation would be to pay for a yearly developer membership, but if that's not possible then, yes, the alternative would be to disable SIP.

Would it be possible to request an exception in this case for my free developer account?

No, as the issue here is technical, not simply cost or policy. The underlying issue here is that the core functionality that separates free and paid accounts is the ability to register and manage bundle ID and development devices, and that functionality is exactly what DriverKit development signing was built on.

Putting that in more concrete terms, the dev only entitlement works by:

1. Registering a bundle ID on the developer portal and enabling the relevant entitlements.
2. Registering the devices you'll be using.
3. Having the portal generate a development provisioning profile for that bundle. That profile will then include the entitlements configured in #1 and the device list from #2 (or what was manually limited during profile creation).

...and the problem for free accounts is that both 1 & 2 don't exist. One thing to understand here is everything I've described above isn't specific to DriverKit, as it's simply the way our signing infrastructure has always worked.

Practically speaking, what you're actually asking for here is a mechanism for free accounts to use/test managed entitlements[1]. That's certainly something you can file a bug asking us to support, but I wanted to make it clear what you were asking for.

[1] A managed entitlement is any entitlement that requires a provisioning profile to function, while a restricted entitlement is a managed entitlement which also requires our approval for your account to use it. The HomeKit entitlement is a managed entitlement, while the DriverKit Entitlements are restricted. Strictly speaking the DriverKit (Development Only) entitlement(s) is the managed variant of the restricted entitlement.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

As a minor note, I think disabling SIP is sufficient, which is significantly less dangerous than disabling AMFI.

I must have done something wrong because I wasn't able to get it working without (temporarily) disabling AMFI.

My personal recommendation would be to pay for a yearly developer membership, but if that's not possible then, yes, the alternative would be to disable SIP.

I may decide to purchase a paid developer account in the future, but I do not think installing personal-made drivers for personal use on personal devices should require a choice between a yearly subscription or disabling important security mechanisms.

That's certainly something you can file a bug asking us to support, but I wanted to make it clear what you were asking for.

Where would I file such a request (/ "bug")? Even if filed, I worry that it is unlikely for this issue to be addressed in reasonable time.

Where would I file such a request (/ "bug")?

This forum post has all the details.

Even if filed, I worry that it is unlikely for this issue to be addressed in reasonable time.

Yes, that's very true. As I talked about in my previous post, this isn't something we could just "enable", as by design, free accounts don't have any access to the underlying signing architecture required to make this work. It would require significant changes to the account type, when then means dealing with issues like how to restrict bundle ID creation so that, for example, free users don't spam bundle creation trying to clog up the system.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware