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 12:04:49 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
cc:	Kyle Moffett <kyle@...fetthome.net>,
	Pantelis Koukousoulas <pktoss@...il.com>,
	Kay Sievers <kay.sievers@...y.org>,
	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, Alan Cox wrote:

> > And just how does initialization and enumeration mess up 
> > virtualization?
> 
> It means that the bus scanning occurs out of control of the virtualised
> environment which might want to control what occurs

With USB this isn't much of an issue.  There are almost no
device-specific parameters affecting enumeration and none affecting
initialization -- understandably, since before initialization the
kernel doesn't know what kind of device it's dealing with.

> > 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).
> 
> If enumeration isn't automatic (or even more so if binding isn't always
> automatic) then the problem doesn't occur.

I disagree.  For one thing, probing of kernel drivers doesn't occur
during enumeration.  So we could have automatic enumeration without
automatic probing, and there would be no problem.  For another, even if
enumeration were the direct cause of some problem, it would still
cause that same problem whenever it occurred, whether automatically or
not.

> > 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.
> 
> Given the layout of devices can change fairly arbitarily would the
> ability to claim specific device identifiers via libusb do the job any
> better.
> 
> ie would it be better to expose an interface via libusb that was
> essentially
> 
> 	reserve_for_userspace(vendorid, devid);

That's a good question.  I'll defer to the interested parties.  
Kyle and Pantelis, what do you think?

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/