From owner-freebsd-usb@freebsd.org Thu Jul 2 09:23:56 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 2487A34EFEF for ; Thu, 2 Jul 2020 09:23:56 +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 49yCMb1tcRz4YV2 for ; Thu, 2 Jul 2020 09:23:54 +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)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id D27FB2601F3; Thu, 2 Jul 2020 11:23:53 +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> <20200625224522.44d6584465cb6e20d17be320@magnetkern.de> <0ec3e5a3-7f31-d1cd-6862-6066c431aa80@selasky.org> <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> From: Hans Petter Selasky Message-ID: <9e14575a-5c8b-28c8-6593-22019a21e7e7@selasky.org> Date: Thu, 2 Jul 2020 11:23:32 +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: <20200702111538.e7edf0ae8d10ec7ede9acebb@magnetkern.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49yCMb1tcRz4YV2 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.60 / 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.28)[-0.277]; 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 09:23:56 -0000 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. > 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? > > 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