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 16:20:14 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Alan Stern <stern@...land.harvard.edu>
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?

> I don't understand this comment.  By "probe" I assume you mean
> "initialize and enumerate", as opposed to calling various drivers'
> probe() routines -- let me know if this isn't what you meant.  If the
> kernel didn't initialize and enumerate devices by default, then when
> would they get initialized and enumerated?

When user space gets an event saying the bus itself exists and asks for
it to be scanned. The most obvious case where its currently broken is
partition tables on disks where you don't always want to read partition
tables automatically.

> 
> If your answer is "When requested by a user process", then I'll go on
> to ask: What about devices containing the root filesystem, the system 
> console, and so on?
> 
> 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

> 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.

> 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);

--
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/