How to develop a driver extension for a USB mass storage device

Question

Created Nov ’23

Replies 2

Boosts 0

Participants 2

I am currently in the process of developing a DEXT for a USB based external mass storage device using the USBDriverKit framework. IOUSBHostInterface is used as the provider to communicate with the interface's endpoints and I am successful in it. As per the IOUSBHostInterface documentation,

To use a host interface object, call Open to create a new session between the interface and your driver. After successfully opening your session, you can request information from the interface and set up pipes to communicate with the interface's endpoints. Remember to close the session you opened in the Stop method of your driver.

However, calling Open gains exclusive access to the USB interface and does not allow other services to access the interface. Also, to let go of the exclusive access, Close method can be called but in the Stop method which is called only once during the lifecycle of the extension (when the DEXT is unloaded).

As a result of this, Apple's mass storage related KEXTs (media and partition related specifically) do not match the interface and so the filesystem of the drive in question does not get mounted whenever the DEXT has matched the interface.

Is this exclusive access a limitation of USBDriverkit or is there any way to get around this issue in this case?

Boost

Answer 1

Frameworks Engineer OP

Apple

Nov ’23

Can you elaborate more on why you need to develop a custom driver for this device? Is it not compliant with the USB Mass Storage Class?

One solution is for your DEXT to match on the IOUSBHostDevice instead. From the IOUSBHostDevice provider, your driver can still access the USB interfaces, endpoints, etc. But the IOUSBHostInterface nubs remain available for matching by Apple KEXTs.

1

Answer 2

abishekmadhuv OP

Nov ’23

@Justin Thank you for replying. I am developing a custom DEXT for sending SCSI vendor commands over USB using the BOT protocol. Earlier, this was possible with a KEXT by having IOSCSIPeripheralDevice nub as the provider class (no exclusive access required). About your suggested solution, even though I can match on the IOUSBHostDevice on the whole, the device has only one interface/IOUSBHostInterface nub and ultimately after setting up the device, I would have to open a session to this interface for sending commands to the bulk endpoint. I suppose this would again lead to the exclusive access issue mentioned above as IOUSBHostInterface::Open call is necessary in this case.

0