Need access to USB device via com.apple.vm.device-access

Question

Created 3w

Replies 4

Boosts 0

Participants 2

IOUSBHostDevice(ioService:options:queue:interestHandler:) with .deviceCapture succeeds — the device is mine, its mass-storage driver terminated. setConfiguration(1, matchInterfaces:) succeeds. The failure is the very next call: IOUSBHostInterface(ioService:options:queue:interestHandler:) on interface 0 returns IOUSBHostErrorDomain -536870199 (kIOReturnInternalError, 0xe00002c9). Exactly one interface node is published under the device, IOServiceGetBusyState reports it idle, and it is refused identically on every retry over several seconds and across repeated re-captures — so this is not a publication race or a stale node. With Full Disk Access granted to the app, the same call claims it on the first attempt, every time.

So I'm stuck. I have no choice but to use FDA which I absolutely do NOT want to do. To anyone from DTS reading this, is this a valid reason for granting me com.apple.vm.device-access?

It looks like using DriverKit might not work either because the Driverkit entitlements are also restricted.

What is the solution here?

Answer 1

DTS Engineer OP

Apple

3w

is this a valid reason for granting me com.apple.vm.device-access?

com.apple.vm.device-access is intended for virtualisation apps that ship on the Mac App Store. Is that what you’re building?

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

Answer 2

starmike OP

3w

I'm trying to connect to a vintage USB storage device. Everything works except this one call which prevents telling the device to sign the data to the drive. Without it, the entire project is useless because asking people to turn on FDA is not responsible and I won't ask them to do it.

So while I understand that the entitlement is intended for virtualization apps that ship on the Mac App Store, elevating privileges in the app doesn't solve the problem or else I'd simply do that and move on. I don't NEED the app to be on the Mac App Store, but I need a way for IOUSBHostInterface(ioService:options:queue:interestHandler:) to succeed without FDA.

So this is a Catch-22.

In fact, here's a chart of everything attempted:

App itself - user (501) - refused — "needs root or com.apple.vm.device-access"
Terminal - root - works
LaunchDaemon - (SMAppService)	root - fails
Daemon + launchctl asuser	- root	- fails
Daemon + audit-session join - root - fails
Daemon + disclaim - root - fails
Admin prompt (do shell script) - root - fails
Self-signed entitlement	—	SIGKILL by AMFI

Answer 3

DTS Engineer OP

Apple

3w

I presume by “FDA” you mean Full Disk Access. If so, I’m not sure how that relates to this. There’s clearly an FDA check in here, but I doubt that com.apple.vm.device-access will get around it.

Do you have concrete evidence that com.apple.vm.device-access will actually help here? It’s been a while since I looked at the details of this, but:

Everything that’s gated by com.apple.vm.device-access has a bypass for root.
When something fails due to the absence of com.apple.vm.device-access, it fails with kIOReturnNotPrivileged, not the kIOReturnInternalError that you’re seeing.

What is the full error you get back here? My experience is that IOUSBHost types are pretty good at populating the userInfo dictionary of the error with useful stuff.

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

Answer 4

starmike OP

2w

Recommended

Quinn, thanks, I figured it out. I was sent down the wrong rabbit hole, but I have everything working now. Thank you.