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]

Message-ID: <1295ed070905220923u32a42c42pd9615e8f9b665815@mail.gmail.com>
Date:	Fri, 22 May 2009 19:23:04 +0300
From:	Pantelis Koukousoulas <pktoss@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Kyle Moffett <kyle@...fetthome.net>,
	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?

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

When a device needs a reset, it typically comes back with a different VID:PID.
So e.g., qemu would have to know both of those, while in the case
where we bind to ports it doesn't have to know either.
(This is good imho since the device may only have a windows driver and we
save the user from some research/experimentation).

I do understand that VID:PID solves the problem with port numbers changing
though, but I think in the end using ports is still easier for the
user with some
effort from the virtualization program implementor.

Note though, I assume that there is / will be a way to reliably
predict the port
number (at least roughly) given a physical port location. E.g., if I plugged
a device to my front left usb connector and it got port number X, it should
be possible to predict what the port number will be if I reconnect the same
device to the same connector. (This doesn't have to hold across reboots).

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