Hi, On 07/29/2012 04:47 PM, Alan Stern wrote: > 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. >
Right, which is actually more or less part of the problem we discussed in the "[PATCH] linux_usbfs: Work around a driver binding race in reset handling" thread. > 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. Having spend some time thinking about this, I believe it is worth it, both to fix this race, as well as to fix the detach-kernel-driver except when it is usbfs race. For a detach-and-claim ioctl it would make sense to not detach (but still / only claim) if the attached driver (already) is usbfs. Nicely fixing the race there too. So if you're ok with adding such an ioctl I'll write a patch for it. <snip> Regards, Hans ------------------------------------------------------------------------------ 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
