On Sun, 29 Jul 2012, Hans de Goede wrote: > So Alan believes, and I agree, that the policy of handling the detaching > of usbfs in a special way is a userspace decision. Note that we've 2 > racy things here btw: > > 1) Testing if a driver is bound and then doing a detach > > This can be fixed (in apps) by simply doing the unbind always and ignore the > ERROR_NOT_FOUND return > > 2) Testing if the driver is usbfs, and if it is not then unbind the kernel > driver (which my patch does / adds). > > This is racy too and cannot simply be fixed. The only solution I can come > up with is adding a "USBDEVFS_NO_USBFS_DISCONNECT" flag with a value of > 0x80000000 which can be or-ed together with the interface number passed > to the USBDEVFS_DISCONNECT ioctl to make it not unbind the usbfs driver > in a non racy way. Combined with a new capability flag for this (I assume > you've seen my capability patches). > > I must say I find this kind of ugly though, if people think this is a good > idea, I'll try to push it upstream, but I believe the race window is so small, > it is not really an issue.
There's yet another race, which this patch doesn't address. If a libusb application detaches an interface's driver and then tries to claim the interface, this leaves a window of time during which somebody else (either a kernel driver or another libusb program) could claim it. The only way to fix this for certain is to add an atomic detach-and-claim call to the kernel. I don't know if this is worth it, though. For the most part, kernel drivers don't automatically try to claim interfaces (the major exception being when a USB device is first discovered). The other remaining possibility is a race between two libusb programs, in which case we don't care very much which one wins. Alan Stern ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
