linux-kernel - Re: usbfs, claiming entire usb devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 7 May 2009 18:47:02 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Kay Sievers <kay.sievers@...y.org>
cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	Pantelis Koukousoulas <pktoss@...il.com>,
	USB list <linux-usb@...r.kernel.org>
Subject: Re: usbfs, claiming entire usb devices

On Thu, 7 May 2009, Kay Sievers wrote:

> >> You have one file per device, and that file has normal unix file
> >> permissions. Userspace can grant access to that file by ownership or
> >> by adding an ACL. What else do we need?
> >
> > We need the ability to prevent the kernel from automatically
> > configuring a device. Â We need the ability to prevent kernel drivers
> > from binding to a device before userspace programs get a chance.
> >
> >> Â Why would the kernel care who
> >> opened the file, when the one was able to get through the normal file
> >> access check?
> >
> > Access checks can't be used, because programs want to stake their claim
> > to the device (and its file) even before the device has been plugged
> > in. Â So there's no file and no ACL to set.
> 
> I see.
> 
> Can't userspace just unbind a possible driver, which is supported by
> libusub? Other such use-cases do that, like the UPS userspace drivers,
> which just unbind the device from a possible in-kernel driver to take
> it over.
> 
> Or is that a specific requirement where things would go wrong when the
> kernel binds to a device first?

You've got it.  Sometimes devices are in a very precarious state (such 
as during a firmware update) and they need to go into a particular 
configuration.  Letting the kernel install some random configuration at 
such times doesn't work.

Similarly, although devices are supposed to be able to switch configs 
at any time, in fact some buggy ones don't allow it.  And while letting 
a kernel driver bind to a device shouldn't cause any narm, with some 
buggy devices it does.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/