Provider entitlements check failed

Here is my mydrv.entitlements file:

I don't think that configuration is correct. I describe the correct configuration here, but the key detail is that the entitlement value is an array with a dictionary inside:

<key>com.apple.developer.driverkit.transport.pci</key>
<array>
	<dict>
		<key>IOPCIPrimaryMatch</key>
		<string>0xFFFFFFFF&amp;0x00000000</string>
	</dict>
</array>

That's more complicated than our other development entitlements, but it's the only configuration that would work without requiring any changes to the system.

If you're sure the entitlement is correct, then please file a bug on this and post the bug number back here. In the bug, please include:

1. A copy of the full app and embedded DEXT that you're trying to install*.

2. If possible, the sample project you're building with.

*Note that, unusually, the build here is actually MORE important than the sample project. For most of these issues all I really need to look at is the signing data of the final product, so starting with a sample project means I have to get the project building in order to test anything.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I tried with your entitlement is it still fails with Entitlements check failed:

kernel DK: mydrv-0x10003fae7: provider entitlements check failed kernel DK: IOUserServer(com.mycompany.mydrvApp.mydrv-0x10003fae7)-0x10003faf1::exit(Entitlements check failed)

Before I file a bug report, does the info.plist need an entry that matches the entitlement?

Thanks

Before I file a bug report, does the Info.plist need an entry that matches the entitlement?

Sort of. The exact behavior here is going to depend on exactly what you're matching, but the typical configuration is that your Info.plist and entitlement configuration would both define IOPCIPrimaryMatch but they wouldn't necessarily be identical. In the case of the dev only entitlement they'd basically "never" be identical, since the dev entitlement matches "everything".

For reference, the configuration of the DEXT I tested the entitlement with is:

Info.plist:
...
IOPCIPrimaryMatch = 0x400014e4&0xf000ffff
...

However, going over the details again, I do have one minor correction. Above I said that the Entitlement.plist value should be "0xFFFFFFFF&0x00000000", however, that's wrong. That's the value that's embedded in the provisioning profile, which escapes the "&". The Entitlement.plist uses the "&" directly, so the correct value is actually:

Entitlement.plist:
...
<key>com.apple.developer.driverkit.transport.pci</key>
<array>
	<dict>
		<key>IOPCIPrimaryMatch</key>
		<string>0xFFFFFFFF&0x00000000</string>
	</dict>
</array>
...

Having said that, this actually raises a more fundamental problem. Xcode validates your entitlement configuration against your provisioning profile, which means the configuration above isn't just "right", it's the only configuration that Xcode will build/sign. That is, in my test project, both of these incorrect configurations:

<key>com.apple.developer.driverkit.transport.pci</key>
<array>
	<dict>
		<key>IOPCIPrimaryMatch</key>
	<string>0xFFFFFFFF&amp;0x00000000</string>
	</dict>
</array>

And:

<key>com.apple.developer.driverkit.transport.pci</key>
<dict>
	<key>IOPCIPrimaryMatch</key>
	<string>0xFFFFFFFF&0x00000000</string>
</dict>

...fail with the error "Provisioning profile "<profile name>" doesn't match the entitlements file's value for the com.apple.developer.driverkit.transport.pci entitlement". In other words, your original configuration shouldn't have been able to build at all.

Have you added the "DriverKit PCI (development)" capability to your DEXT?

The only way I can see Xcode building any of those invalid configurations is that the capability wasn't added to the project, so Xcode didn't have anything to check the entitlement.plist against.

Also, one note/warning as you're getting started with this. As described here, DEXT inherits from the kernel a 63-character bundle ID limit and a specific CFBundleVersion. Some of our sample projects may cross that limit, in which case you should just change the bundle ID to something shorter/reasonable.

Finally, for reference, the IOPCIFamily project is largely open source, including its DriverKit implementation. The general loading machinery is not open source (so you can't see what leads to this call), but the family-level entitlement validation is in IOPCIDevice::matchPropertyTable().

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Yes I have added the DriverKit PCI (development) capability and my provisionprofile does show a com.apple.developer.driverkit.transport.pci with IOPCIPrimaryMatch = "0xFFFFFFFF&0x00000000" when looking at it in finder.

When I write the entitlements file with Xcode, it automatically write it as this when looking at the file with a text editor.

<key>com.apple.developer.driverkit.transport.pci</key>
<array>
	<dict>
		<key>IOPCIPrimaryMatch</key>
<string>0xFFFFFFFF&amp;0x00000000</string>
	</dict>
</array>

So I think it is correct.

I did stumble upon the bundle ID limit a couple of days ago when I was trying to make the DriverKitUserClientSample example to work, which still I haven't been able to. I have another post for it which is awaiting further help if you can take a look at it (Problem with DriverKitUserClientSample).

Thanks

I did stumble upon the bundle ID limit a couple of days ago when I was trying to make the DriverKitUserClientSample example to work, which still I haven't been able to.

Please file a code support issue and email the file* (build and test project) so I can see what's going on.

*I believe you'll receive an email acknowledging your issue and you can reply to that with the files attached.

I have another post for it which is awaiting further help if you can take a look at it (Problem with DriverKitUserClientSample).

See my reply there.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Done.

Case-ID: 17006366 in case you need it.

When I write the entitlements file with Xcode, it automatically write it as this when looking at the file with a text editor.

Yes. There's been a bit of confusion around this, so I actually wrote up a detailed description of what's going on, complete with screenshots.

Case-ID: 17006366 in case you need it.

Just replied on that TSI!

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware