linux-kernel - Re: How to tell whether a struct file is held by a process?

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:	Fri, 22 May 2009 11:54:43 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Kay Sievers <kay.sievers@...y.org>
cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Kyle Moffett <kyle@...fetthome.net>,
	Pantelis Koukousoulas <pktoss@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: How to tell whether a struct file is held by a process?

On Fri, 22 May 2009, Kay Sievers wrote:

> On Fri, May 22, 2009 at 17:12, Alan Stern <stern@...land.harvard.edu> wrote:
> > Anyway, enumeration isn't the problem. Â The real problem has two parts:
> >
> > Â  Â  Â  Â Automatic probing and binding of kernel drivers, including
> > Â  Â  Â  Â selection and installation of a configuration (this really
> > Â  Â  Â  Â _does_ mess up virtualization).
> >
> > Â  Â  Â  Â The fact that a window exists immediately after the
> > Â  Â  Â  Â registration of a newly-detected device before a user
> > Â  Â  Â  Â process can lock the device file. Â During this window,
> > Â  Â  Â  Â other processes could open the file.
> >
> > The second part can be solved (among cooperating processes) by use of
> > port-lock files, with no kernel involvement. Â The first part does
> > require a kernel interface of some sort, but it wouldn't have to be
> > complicated. Â The mere fact that a port-lock file was open could be
> > enough to prevent automatic configuration, probing, and binding.
> >
> > Does this seem like reasonable approach?
> 
> Would releasing the "lock" trigger a kernel-driver-binding call?

No.  If the lock owner wants to bind kernel drivers, it can use the
existing API in libusb after releasing the lock.  This might cause
problems if the owning process terminates abnormally, but I think we
can live with that.

> The lock will always lock all devices of a specific hub?

The idea is that there will be one lock file per port.  So for example, 
a hub device with four ports might contain inside its sysfs device 
directory: ports/1, ..., ports/4.

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/