Hi Jan,
On 2020-07-03 09:51, Jan Behrens wrote:
Yes, and we have one or two firmware loading utilities in base still
using them.
Except that /dev/usb/X.Y.0 (which is linked by /dev/ugenX.Y) controls
access rights to the device through libusb, right?
Yes, that is correct.
Yes, but opening /dev/ugenX.Y doesn't mean that kernel device drivers
are detached from this device.
Can/does a kernel device driver restrict what a user can do with the
device when the kernel driver is active? Or does access to the device
always enable a user to mess up things badly?
The kernel device driver can not restrict what the user-space driver can
do. Yes, user-space can mess up the device totally.
User-space drivers are requested to create a uniq PID file, to avoid
clashes with multiple drivers on the same interface and may use
libusb_claim_interface() to tell the kernel to detach any drivers on
that specific interface.
If the kernel refuses to give up control, is the user-space program
denied access? If yes, I can generally understand why you don't want a
USB reset to be initiated by a user-space program (at least as long
there are kernel drivers attached).
The FreeBSD USB stack has no concept of exclusive access to USB
endpoints. Simply if both kernel and user-space attach to the same
device, user-space will receive half of the USB packets and the kernel
the other half.
If you for example load the LimeSDR two times for the same ugenX.Y
device, then the interface communication might stop working, even though
no error is reported.
Thus the lock of user-space drivers is only advisory and not enforced?
Right, it is not enforced.
How about if a kernel driver uses the device? Can/does the kernel block
out a user-space driver that would mess with the kernel's operation on
the device?
No, it is all transparent. Kernel drivers cannot block user-space, but
user-space can detach kernel-space. That's all.
I see three possible approaches currently:
1. Allowing a USB reset if the user has access to /dev/ugenX.Y (might
allow users to mess with kernel's operation on a device, unless the
problem exists anyway, see my questions above).
2. Allowing a USB reset if the user has access to /dev/ugenX.Y and
there are other prerequirements fulfilled (e.g. a sysctl setting to
enable it globally, which might not be fine-graded enough, or the
requirement that there is currently no kernel driver attached, or a
combination thereof).
3. Providing a way to grant "reset permissions" on a per-device basis
(might be overkill, and not really needed).
Maybe you're right we should allow this for non-root aswell. I need to
think about it!
--HPS
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
