[linux-usb-devel] Artificial limits in usbfs

2006-05-16 Thread Micah Dowty
Hi,

Some months ago I raised my concerns about artificial
limits in usbfs, by submitting two very simple patches:

http://article.gmane.org/gmane.linux.usb.devel/40811
http://article.gmane.org/gmane.linux.usb.devel/40812

The issue hasn't been resolved yet, so I'd like to briefly
restate the points made thus far and solicit any further
comments on the issue.

The proc_do_submiturb() implementation in devio.c tests
URBs against several arbitrary limits. The two I'm most
concerned about are:

1.
   /* min 8 byte setup packet, max arbitrary */
   if (uurb-buffer_length  8 || uurb-buffer_length  PAGE_SIZE)
   return -EINVAL;

2.
   if (isopkt[u].length  1023) {
   kfree(isopkt);
   return -EINVAL;
   }

The limit in (1) makes it impossible to write userspace
drivers for devices which require a full 4K of data in
their control transfers. The limit in (2) makes it
impossible to support high-bandwidth USB 2.0 isochronous
transfers from userspace.

My solution was to bump (1) from PAGE_SIZE to PAGE_SIZE*2,
and (2) from 1023 to 6144, but both suggestions were
relatively arbitrary.

David Brownell suggested replacing the limit in (1) with
4K+8 bytes, and he pointed out that the test in (2) should
respect the device's descriptors. That started a discussion
on whether the tests in devio.c should enforce validity
according to the USB spec, or whether they should simply
prevent userspace code from causing overflows or unusually
large kmalloc()s.

I would submit that it isn't the usbfs layer's job to
enforce the USB spec. There are two reasons for this:

- Some USB devices are broken, and it should still be
  possible to write drivers for them on Linux- even
  user-space drivers.

- Any portions of the USB spec that Linux does choose
  to enforce should be enforced in the main URB submit
  paths, rather than at the usbfs layer. The class of
  URBs which kernel code can submit but userlevel code
  cannot submit should be limited only to those which
  have a danger of affecting system stability.

I'd be very interested to hear more opinions on this
issue.

--Micah


---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel


Re: [linux-usb-devel] Artificial limits in usbfs

2006-05-16 Thread Greg KH
On Tue, May 16, 2006 at 03:00:52PM -0700, Micah Dowty wrote:
 I would submit that it isn't the usbfs layer's job to
 enforce the USB spec. There are two reasons for this:
 
 - Some USB devices are broken, and it should still be
   possible to write drivers for them on Linux- even
   user-space drivers.
 
 - Any portions of the USB spec that Linux does choose
   to enforce should be enforced in the main URB submit
   paths, rather than at the usbfs layer. The class of
   URBs which kernel code can submit but userlevel code
   cannot submit should be limited only to those which
   have a danger of affecting system stability.
 
 I'd be very interested to hear more opinions on this
 issue.

I agree.  Care to resubmit your patches and CC: the USB maintainer next
time so he makes sure to reply to your patches?  :)

thanks,

greg k-h


---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642
___
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel