From owner-freebsd-usb@freebsd.org Thu Jul 2 10:18:32 2020 Return-Path: Delivered-To: freebsd-usb@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BFB35350DFD for ; Thu, 2 Jul 2020 10:18:32 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49yDZb5cF5z4ccN for ; Thu, 2 Jul 2020 10:18:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 75BD82604E8; Thu, 2 Jul 2020 12:18:24 +0200 (CEST) Subject: Re: USB reset fails when using a LimeSDR Mini on FreeBSD To: Jan Behrens Cc: "freebsd-usb@FreeBSD.org" References: <20200625121052.e9f7e7cbeb68fad264ec80a9@magnetkern.de> <20200626135151.e5542cf97fad213c4ad661f2@magnetkern.de> <5c0729f9-9e98-52f7-a5cb-6c5dfd2287a3@selasky.org> <20200626172851.872f3a08fa6e632666683230@magnetkern.de> <20200627144419.f14371695d9b62ea99106c4a@magnetkern.de> <20200627173604.7f7b7777140e66dbad812fc7@magnetkern.de> <20200627180420.4b8012fb@ernst.home> <20200702103523.adb0566bcc7b6e354905a8a5@magnetkern.de> <97c8fd11-9200-dff7-4c68-b0b80cc44871@selasky.org> <20200702104743.223e98c325806025704703f2@magnetkern.de> <20200702111538.e7edf0ae8d10ec7ede9acebb@magnetkern.de> <9e14575a-5c8b-28c8-6593-22019a21e7e7@selasky.org> <20200702120655.73d1111e2de81c626be78139@magnetkern.de> From: Hans Petter Selasky Message-ID: <8ac365f3-3d33-4730-622e-e66f29dd5938@selasky.org> Date: Thu, 2 Jul 2020 12:18:02 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200702120655.73d1111e2de81c626be78139@magnetkern.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yDZb5cF5z4ccN X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of hps@selasky.org designates 88.99.82.50 as permitted sender) smtp.mailfrom=hps@selasky.org X-Spamd-Result: default: False [-2.85 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net:c]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-1.001]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.53)[-0.525]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.02)[-1.020]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2020 10:18:32 -0000 Hi Jan, On 2020-07-02 12:06, Jan Behrens wrote: > On Thu, 2 Jul 2020 11:23:32 +0200 > Hans Petter Selasky wrote: > >> On 2020-07-02 11:15, Jan Behrens wrote: >>> On Thu, 2 Jul 2020 10:54:27 +0200 >>> Hans Petter Selasky 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. > Let me explain, now you are getting me into dirty details :-) This device is used for all of LibUSB interfaces and gives access to all endpoints: /dev/usb/X.Y.0 These devices are legacy devices, which allow direct access to the endpoint via the shell. They are there to support the old user-space model FreeBSD had. And they are re-created when you reset/reconfigure a USB device. Actually you can "echo > /dev/usb/X.Y.N" to write directly to an endpoint from user-space. But don't do that unless it is a modem endpoint which support AT commands for example. /dev/usb/X.Y.[1..15] > Is it correct that 2.2.0 identifies the device as a whole? Yes, this is correct. >> >> 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. > In FreeBSD and LibUSB there is no such concept. Everything is oriented around interfaces. There is a function to claim an interface, but not the device itself. (man libusb_claim_interface) >> >>> >>> 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 > --HPS