USB reset fails when using a LimeSDR Mini on FreeBSD

[Jan Behrens]

On Thu, 2 Jul 2020 11:23:32 +0200
Hans Petter Selasky <hps at selasky.org> wrote:

> On 2020-07-02 11:15, Jan Behrens wrote:
> > On Thu, 2 Jul 2020 10:54:27 +0200
> > Hans Petter Selasky <hps at selasky.org> wrote:
> > 
> >> On 2020-07-02 10:47, Jan Behrens wrote:
> >>> But wouldn't both drivers require access to the entries in /dev ?
> >>
> >> Yes, user-space drivers would require access to /dev, yes, but kernel
> >> drivers not, like mouse, keyboard, storage, network.
> >>
> >>> Thus not every user could mess with any USB device, or do I get it
> >>> wrong?
> >>
> >> A so-called composite USB device may appear like a USB storage device
> >> (kernel driver) and a security token (firefox). Firefox can only grab
> >> the device if you set the proper permissions for /dev of course, but the
> >> reset device IOCTL then also becomes possible, which is why we currently
> >> block it for non-root.
> >>
> >> --HPS
> > 
> > Okay, so if I understand it right, the problem is due to devices that
> > shall be partly accessible by root, and partly by users. Some device
> > nodes (e.g. /dev/usb/2.2.1 ) while others (e.g. /dev/usr/2.2.2 ) are
> > limited to root access only. An USB reset always affects all devices
> > (e.g. also /dev/usb/2.2.2, 2.2.3, etc.), right?
> 
> Yes, correct.

Does /dev/usb/2.2.0 (in the given example) represent the device as a
whole, or is it just another subdevice? (What's the correct term for
"subdevice" in this context by the way? I assume "interface"?)

I experienced that /dev/usb/2.2.0 and /dev/usb/2.2.1, 2.2.2, 2.2.3,
etc. get treated differently when I reset the LimeSDR Mini with
"usbconfig -u 2 -a 2 reset". The devices 2.2.1 and up are supposingly
re-created (and have their access rights reset), while the device 2.2.0
maintains any manually changed access rights.

Is it correct that 2.2.0 identifies the device as a whole? Or is this
just the first/default interface? Is there any node in the /dev
filesystem, which semantically refers to the whole hardware device?

> 
> > Disregarding implementation complexity, I'd say that resetting a USB
> > device should only be possible if a user has access to all sub-devices
> > (or even better to a special device node that represents the device as
> > a whole).
> 
> Maybe we can check if any kernel side drivers are attached at the time 
> of reset device. It might be racy, because kernel drivers can be loaded 
> and attached at any time. But it will work.
> 
> What do you think?

I'm not sure if this is (from a semantic point of view) the best thing
to do. I would say you should only be able to reset a device if you
have been granted access to the device as a whole (including all
interfaces/subdevices/whatever), as the reset seems to affect all of
those.

> 
> > 
> > That sounds better than adding a sysctl option to me. But I assume that
> > would require a lot of changes in the code?
> 
> If a simple rule can be formulated, I could implement it in the generic 
> USB kernel code.
> 
> --HPS

Regards,
Jan