Don't know why my OS X kext with a lower probe score is being matched

1
votes

I am trying to selectively screen and disable certain USB devices. For that purpose I have written an IOUSBInterface driver that specifies wildcards for idProduct, idVendor, and bcdDevice. Anytime I do not want to disable a given device, I set probeScore to 0 and return.

The probeScore approach works in almost all cases, and I can see my driver considering each USB device in turn in system.log. But in the case of the Bluetooth USB Host Controller, the kernel attaches my driver to it despite my probe score of 0. By comparison, if my driver is not present, the Bluetooth USB Host Controller matches with a probe score of 90,000.

It is true that my driver specifies OSBundleRequired as Root, but the Bluetooth USB Host Controller specifies OSBundleRequired as Safe Boot, which would seem to put them on the same footing. On the other hand I'm having the same Yosemite Bluetooth problems as others, and my Bluetooth mouse doesn't respond until after I login, suggesting that the Bluetooth USB Host Controller might not be getting loaded until after boot time.

1
macosbluetoothiokitkernel-extension
I do have FileVault 2 enabled on the machine, which may affect what is visible before unlocking my drive. When I boot in single user mode and try to explicitly load /System /Library/Extensions/IOBluetoothFamily.kext/Contents/PlutIns/BroadcomBluetoothHostControllerUSBTransport.kext, I get an invalid signature error even though the system has no problem loading that driver once I log in. Perhaps I need to ask this question on Ask Different. – Neil Steiner
The kextcache command line tool has a -print-diagnostics flag which might help pinpoint the issue. – pmdj
@pmdj I'm having a bit of trouble with kextcache. I tried sudo kextcache -system-caches -print-diagnostics -v 6 and some other options, but didn't really find what I was looking for. What usage did you have in mind? – Neil Steiner
It would have shown any reason why loading your kext might not work. Evidently there is none. See my answer for what I suspect might be happening. – pmdj

1 Answers

1
votes

Completely rewritten answer as I'd misunderstood the question

First off, from the horse's mouth:

"Note that you should never add your own IOProbeScore property to a USB driver's property list."

That's probably why you're not having much joy with the probe score. (Note that the above recommendation only applies to USB devices; disregard for Thunderbolt etc.)

If modifying your personality matching dictionary to not match the device in question isn't practical (it sounds like you want to decide at runtime, so that's a good reason) then override your driver's probe() method and selectively return this or NULL from it depending on whether you want your (blocker) driver to claim the device or not. Returning NULL from probe() should always work - if it's causing trouble, you most likely have a bug in your code somewhere.