CODEWITHSUNDEEP
macosusbhidiokitkernel-extension
Geoff
Geoff

Reputation: 29

Codeless kext, precluding HID manager for USB device takeover in OS X Big Sur

I've done extensive reading on this, but I'm still stumped. I'm trying to call USBInterfaceOpen for a USB Device that I need direct read/write access to, but I get an exclusive access error.

There seem to be 2 possibilities here: 1) use the HID interface or 2) do a codeless kext to get to the device before OS X's HID Manager does.

So possibility 1 is not going to work, it's not recognized as a storage or network device and nothing is created in the /dev tree that would allow standard POSIX calls.

And possibility 2 is not going well. Apple seems to have really locked things down, and I get "Bad code signature" errors when loading trying to load my codeless kext (with just a .plist):

Authenticating extension failed: Bad code signature" UserInfo={NSLocalizedDescription=Authenticating extension failed: Kext com.blackrock.cerestim v1.0.0 in codeless kext bundle com.blackrock.cerestim at /private/var/db/KernelExtensionManagement/Staging/com.blackrock.cerestim.ohqHdy/Cerestim.kext:

I am really stuck. Does anyone have any ideas?

Upvotes: 1

Views: 504

Answers (1)

pmdj
pmdj

Reputation: 23428

OK, there's a lot going on here:

  1. For code signing kexts, you need to:

    • Have a special kext signing variant of the Developer ID signing certificate (granted by Apple with special permission)
    • Sign the kext with this certificate
    • Submit the kext for notarisation using altool (or notarytool)

  2. As of Big Sur, having a codeless kext is no longer sufficient for preventing Apple's drivers from capturing devices during early boot, because Apple's own kexts now get matching priority during this early phase due to the tiered kext "collections" (see kmutil's man page) where 3rd party kexts always end up in the "auxiliary" collection which gets loaded after everything from Apple.

  3. At least with HID devices, you should be able to tell the HID subsystem to release its grasp of the device. Have you tried gaining access using USBDeviceOpenSeize()?

If the above doesn't answer your question, please post the failing code and the subtree of the ioreg -lirc IOUSBHostDevice output for your device.

Upvotes: 1

Related Questions