DriverKit Access to Built-In MacBook Trackpad Raw HID Reports

Question

Created 2w

Replies 4

Boosts 1

Participants 4

We are trying to intercept raw reports from the built-in MacBook haptic trackpad using a DriverKit IOUserHIDEventDriver dext.

Our dext installs and activates successfully:

OSSystemExtensionRequest finishes with result 0
systemextensionsctl list shows the dext as activated enabled
the dext is embedded correctly in the app bundle

However, it never attaches to the built-in trackpad IOHIDInterface. ioreg shows the built-in trackpad interface still matched only by Apple’s HID dext. We also observed that Apple’s own HID dext appears to use com.apple.developer.driverkit.builtin, while that entitlement is not available in our provisioning profile.

Our dext specifically relies on:

IOUserHIDEventDriver::handleReport(...)
SetProperties() with kIOHIDEventDriverHandlesReport

Questions:

Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface?
Is that entitlement public/requestable, or Apple-internal only?
At what stage is it enforced: activation, personality matching, provider attach, or before Start()?
If builtin is not available to third parties, is there any officially supported way to receive raw reports from the built-in MacBook trackpad in DriverKit?

Our conclusion so far is that activation succeeds, but provider binding to the built-in trackpad fails due to built-in-only authorization/matching.

Boost

Answer 1

Skygreed OP

1w

i need too...!

1

Answer 2

froglike6 OP

1d

Could you please tell me when I am supposed to receive an alternative response? If that is not possible, you should at least have the courtesy to say so clearly.

0

Answer 3

DTS Engineer OP

Apple

17h

froglike6, It’s not clear whether your response was addressed to me or Skygreed. If it’s for me, be aware that my comment above was purely administrative. Skygreed added a reply to your thread, so I wanted to make sure that anyone finding this thread was aware of their thread.

As to the technical aspects of this issue, and similarly for Skygreed’s issue, I’m not the right person to address that. I don’t have any in-depth experience with HID stuff.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

DTS Engineer OP

Apple

9h

I’m not the right person to address that. I don’t have any in-depth experience with HID stuff.

Sorry, that would be "me" and I apologize for having missed your post until now.

(thanks to Quinn for giving me a heads up!)

Questions reordered for clarity:

At what stage is it enforced: activation, personality matching, provider attach, or before Start()?

First off, as general background, I have a forum post here that has an overview of the IOKit->DEXT loading flow. In any case, entitlement validation is implemented as a secondary stage of the IOKit passive match process, with each family handling the details of entitlement validation. For reference, this is how the PCI Family does these checks.

Is com.apple.developer.driverkit.builtin required for a third-party IOUserHIDEventDriver to match a built-in internal trackpad IOHIDInterface?

I haven't actually looked at the HID families implementation in detail so it's possible there are other requirements, but, yes, at a minimum the built-in entitlement is required. I'd expect that behavior to be common to most (if not all) DriverKit families. See the PCI DriverKit link above for an example.

Is that entitlement public/requestable, or Apple-internal only?

"com.apple.developer.driverkit.builtin" is not a public entitlement.

If built-in is not available to third parties, is there any officially supported way to receive raw reports from the built-in MacBook trackpad in DriverKit?

What are you actually trying to do? I can think of two approaches (see below), but my answer might change with more context about your larger goal.

If you're wanting to test/experiment, then disabling SIP/AMFI would let you "give" your DEXT the built-in entitlement, at which point you can do whatever you want. That's obviously not something you'd ever want to ship, but I'm sure there are cases where this approach could be useful.
If your goal is to actually ship something... then I'm not sure. I'm going to talk about this more on Skygreed post, but the core issue here is the difference between capturing the HID device (so you receive all HID events) and "filtering" events (so you receive them before they're passed to the system). I don't think you'll be able to "filter" reports, but you might be able to seize the device itself. If you also wanted to generate events, then the typical approach would be to seize the HID device, then emit new HID events to the system through that virtual HID device.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0