Re: usbfs, claiming entire usb devices

Re: usbfs, claiming entire usb devices

[Alan Stern]

There is a proposal afoot to give user programs the ability to claim
ownership of an entire USB device, rather than just individual
interfaces.  In fact, we'd like processes to be able to own whatever
device gets plugged into a particular port on a particular hub.

The question is how the API should work.  A simple approach is to have
a sysfs or usbfs file correspond to each port; when a process opens the
file it would be granted ownership of any device plugged into that
port.  Since the file is automatically closed when the process ends, we
wouldn't have to worry about ownership never getting released.

But there's a snag.  When a process goes to open the usbfs file for a
device, the kernel needs to know whether or not the process owns that
device.  In other words, we need to figure out whether or not the
process has opened the corresponding port file.

Is there a simple way to do this?  Is it reasonable to search through 
all the process's fd's, looking for one that matches a particular 
inode?

Or would a completely different API approach be better?

Thanks,

Alan Stern

Re: usbfs, claiming entire usb devices

[Kay Sievers]

On Thu, May 7, 2009 at 21:55, Alan Stern <stern@rowland.harvard.edu> wrote:
> There is a proposal afoot to give user programs the ability to claim
> ownership of an entire USB device, rather than just individual
> interfaces.  In fact, we'd like processes to be able to own whatever
> device gets plugged into a particular port on a particular hub.
>
> The question is how the API should work.  A simple approach is to have
> a sysfs or usbfs file correspond to each port; when a process opens the
> file it would be granted ownership of any device plugged into that
> port.  Since the file is automatically closed when the process ends, we
> wouldn't have to worry about ownership never getting released.
>
> But there's a snag.  When a process goes to open the usbfs file for a
> device, the kernel needs to know whether or not the process owns that
> device.  In other words, we need to figure out whether or not the
> process has opened the corresponding port file.
>
> Is there a simple way to do this?  Is it reasonable to search through
> all the process's fd's, looking for one that matches a particular
> inode?
>
> Or would a completely different API approach be better?

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? Why would the kernel care who
opened the file, when the one was able to get through the normal file
access check?

Or did you mean some magic for an entire tree of devices below some
port? Like some sort of permission inheritance in the kernel?

Kay

Re: usbfs, claiming entire usb devices

[Alan Stern]

On Thu, 7 May 2009, Kay Sievers wrote:

> On Thu, May 7, 2009 at 21:55, Alan Stern <stern@rowland.harvard.edu> wrote:
> > There is a proposal afoot to give user programs the ability to claim
> > ownership of an entire USB device, rather than just individual
> > interfaces.  In fact, we'd like processes to be able to own whatever
> > device gets plugged into a particular port on a particular hub.
> >
> > The question is how the API should work.  A simple approach is to have
> > a sysfs or usbfs file correspond to each port; when a process opens the
> > file it would be granted ownership of any device plugged into that
> > port.  Since the file is automatically closed when the process ends, we
> > wouldn't have to worry about ownership never getting released.
> >
> > But there's a snag.  When a process goes to open the usbfs file for a
> > device, the kernel needs to know whether or not the process owns that
> > device.  In other words, we need to figure out whether or not the
> > process has opened the corresponding port file.
> >
> > Is there a simple way to do this?  Is it reasonable to search through
> > all the process's fd's, looking for one that matches a particular
> > inode?
> >
> > Or would a completely different API approach be better?
> 
> 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.

> Or did you mean some magic for an entire tree of devices below some
> port? Like some sort of permission inheritance in the kernel?

No, just the device in that port.

Alan Stern

Re: usbfs, claiming entire usb devices

[Kay Sievers]

On Thu, May 7, 2009 at 23:18, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Thu, 7 May 2009, Kay Sievers wrote:
>> On Thu, May 7, 2009 at 21:55, Alan Stern <stern@rowland.harvard.edu> wrote:
>> > There is a proposal afoot to give user programs the ability to claim
>> > ownership of an entire USB device, rather than just individual
>> > interfaces.  In fact, we'd like processes to be able to own whatever
>> > device gets plugged into a particular port on a particular hub.
>> >
>> > The question is how the API should work.  A simple approach is to have
>> > a sysfs or usbfs file correspond to each port; when a process opens the
>> > file it would be granted ownership of any device plugged into that
>> > port.  Since the file is automatically closed when the process ends, we
>> > wouldn't have to worry about ownership never getting released.
>> >
>> > But there's a snag.  When a process goes to open the usbfs file for a
>> > device, the kernel needs to know whether or not the process owns that
>> > device.  In other words, we need to figure out whether or not the
>> > process has opened the corresponding port file.
>> >
>> > Is there a simple way to do this?  Is it reasonable to search through
>> > all the process's fd's, looking for one that matches a particular
>> > inode?
>> >
>> > Or would a completely different API approach be better?
>>
>> 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?

Kay

Re: usbfs, claiming entire usb devices

[Alan Stern]

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

Re: usbfs, claiming entire usb devices

[Kay Sievers]

On Fri, May 8, 2009 at 00:47, Alan Stern <stern@rowland.harvard.edu> wrote:

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

I see.

You mentioned earlier, that you would need to match the holder of the
"lock" and the one that accesses the device?

Wouldn't it be sufficient already, if you can take a "lock" at the
specific port, that prevents the kernel to access the device when it
shows up?

You thought of supporting a number of different users, with different
uids, or would that be a root-only action?

Thanks,
Kay

Re: usbfs, claiming entire usb devices

[Alan Stern]

On Fri, 8 May 2009, Kay Sievers wrote:

> You mentioned earlier, that you would need to match the holder of the
> "lock" and the one that accesses the device?

Yes.  That is, a process shouldn't be allowed to access a locked device 
unless that process is the lock holder.

> Wouldn't it be sufficient already, if you can take a "lock" at the
> specific port, that prevents the kernel to access the device when it
> shows up?

I don't know how the people requesting this feature would feel about
that.  They seem to want to lock out other processes as well as locking
out the kernel.

> You thought of supporting a number of different users, with different
> uids, or would that be a root-only action?

A typical use case would be somebody running an emulator like QEMU.  In 
theory there could be multiple QEMU processes running concurrently, 
each owning a different set of ports.  The uids might be different or 
they might all be the same.

Setting the lock permissions would be up to userspace.

Alan Stern

Re: usbfs, claiming entire usb devices

[Kay Sievers]

On Fri, May 8, 2009 at 16:06, Alan Stern <stern@rowland.harvard.edu> wrote:
> On Fri, 8 May 2009, Kay Sievers wrote:
>
>> You mentioned earlier, that you would need to match the holder of the
>> "lock" and the one that accesses the device?
>
> Yes.  That is, a process shouldn't be allowed to access a locked device
> unless that process is the lock holder.

You think the pid or the uid would make more sense?

>> Wouldn't it be sufficient already, if you can take a "lock" at the
>> specific port, that prevents the kernel to access the device when it
>> shows up?
>
> I don't know how the people requesting this feature would feel about
> that.  They seem to want to lock out other processes as well as locking
> out the kernel.

Might be useful, yeah. I could think of use cases where a specific uid
wants to lock a device, by holding the lock file open, and only the
same uid (could be a different pid) can claim the device from
userspace.

>> You thought of supporting a number of different users, with different
>> uids, or would that be a root-only action?
>
> A typical use case would be somebody running an emulator like QEMU.  In
> theory there could be multiple QEMU processes running concurrently,
> each owning a different set of ports.  The uids might be different or
> they might all be the same.
>
> Setting the lock permissions would be up to userspace.

Yeah, sounds fine.

Kay

Re: usbfs, claiming entire usb devices

[Alan Cox]

> > Yes.  That is, a process shouldn't be allowed to access a locked device
> > unless that process is the lock holder.
> 
> You think the pid or the uid would make more sense?

How about neither ?

The standard Unix behaviour is to open the file O_EXCL if you want
exclusivity. Neither uid or pid are helpful or work in the many
environments where you want security - in particular where (as is very
common with user space driver type code) you want parts of your code
running setuid and parts not, as two processes with different pid and uid
values.

If O_EXCL is interpeted as exclusive access (versus kernel and re-open of
the same node) then you can implement the rest of the sematics in user
space.

Alan

Re: usbfs, claiming entire usb devices

[Kay Sievers]

On Sat, May 9, 2009 at 19:15, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> > Yes.  That is, a process shouldn't be allowed to access a locked device
>> > unless that process is the lock holder.
>>
>> You think the pid or the uid would make more sense?
>
> How about neither ?
>
> The standard Unix behaviour is to open the file O_EXCL if you want
> exclusivity. Neither uid or pid are helpful or work in the many
> environments where you want security - in particular where (as is very
> common with user space driver type code) you want parts of your code
> running setuid and parts not, as two processes with different pid and uid
> values.
>
> If O_EXCL is interpeted as exclusive access (versus kernel and re-open of
> the same node) then you can implement the rest of the sematics in user
> space.

Hmm, but his is a lock for "future" device, which did not even show up
at that point the "lock" will be taken. The files would not be opened
a second time.

The lock-file and the device file are two different files, both would
be opened only by one process - and we are playing around here with
the idea how to connect these both processes.

Thanks,
Kay