Detaching a (Linux) kernel driver

[tommie]

I'm buildling a USBTMC device, which I'd like to access with WebUSB. When my device connects, the interface is immediately bound to the Linux usbtmc kernel driver, and claimInterface fails with NetworkError.

libusb provides libusb_detach_kernel_driver to explicitly hijack the device.

I can't find any information in the WebUSB specification about how implementations are supposed to handle this case. If I have requested the device, the user likely wants the webpage detaching the driver ("just make it work.") To me, it seems claimInterface should use always try to detach the kernel driver, but it would be nice with some guidance on how disruptive claimInterface ought to be.

For anyone looking for an answer, this udev rule is for a Raspberry Pi RP2040 that can then be claimed by WebUSB:

DRIVER=="usbtmc", ACTION=="add", ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000a", RUN+="/bin/sh -c 'echo -n %k >%S%p/driver/unbind'"

Caveat emptor: I don't know how this works on other OSes, but I don't think it matters for the general question of how eager claimInterface should be to succeed.

[bongbui321]

yeah, I encounter the similar issue on Ubuntu 20.04 that claim the interface automatically. I used a simple script in python to detach the kernel driver. I think the reason they don't implement that feature is because it is different for different platforms and it touches a lot of low-level stuff for different platform, not sure if there is a general fix for that. I can confirm that you don't face the same issue on MacOS not sure on Windows.
Do you have any idea on how to solve the issue without touch the udev or running the python script like I did for linux?
I'm developing a tool to send usb data to the device for end users and I don't want them to go down to the low level such as that

[reillyeon]

There are two pieces to this,

1. When implementing WebUSB the principle we used to avoid introducing potential security issues was that it should not preempt the existing system configuration. The assumption there was that if there is a kernel driver then the system expects applications to use a higher-level interface provided by that driver instead of the low-level USB interface. There's some discussion in Chromium issue 40137537 about detaching kernel drivers on Android specifically which are known to be unused and thus that principle doesn't apply.
2. On platforms other than Linux overriding a kernel driver is much more difficult. For example on Windows it requires calling system configuration APIs that require administrator privileges and the effect persists across reboots.

[tommie]

Thanks, that's useful to know.

If Windows requires invasive action to relinquish control to the browser, I understand the answer to my question will be "claiming an interface should not be disruptive" for the foreseeable future. Thus I should redesign the device to use a vendor subclass.

Since the user has already performed an action to approve opening the device, taking a defensive position due to security seems questionable. But given the above, I don't think it matters.

My question has been answered. I'm guessing it doesn't need further clarification in the spec, though I think a note that this is intended behavior would be useful.

[OlegNitz]

Regarding Chromium issue 40137537: this feature was implemented and is being launched for Chromium on Android with the hardcoded allowlist of USB drivers that can be detached: usblp, ftdi_sio and cdc_acm. The cdc_acm driver provides interfaces of two classes: Communications and CDC Data, but the allowlist only contains interfaces of Communications class with AT-command sets or without any protocol set.

Note: If you need to claim the CDC Data interface, you have to claim its control interface first, this will detach the cdc_acm driver, and then you will be able to claim the CDC Data interface.