On Tue, 18 Oct 2005 11:05:33 -0400, Christopher Li <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 18, 2005 at 10:13:33AM -0700, Greg KH wrote:
> I am a little nervous no check have been done to what ioctl it is
> passing. Most of the case you don't need to convert the buffer, but
> what if there is some ioctl need to do something special.
You do not have to be nervous, because USB ioctls are not unstructured.
These ioctls do not receive __user pointers, unsigned longs, or things
freely interpreted. They are defined to receive one buffer, and they
are not expected to perform any copy_from_user/copy_to_user.
The struct file_operations has ioctl which looks like this:
int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned
long);
The unsigned long here is often a pointer to user buffer.
However, in USB case, struct usb_driver has ioctl like this:
int (*ioctl) (struct usb_interface *intf, unsigned int code, void *buf);
The *buf is not passed from user mode. It's an honest to goodness
kmalloc'ed buffer.
> On the safe side, I am expecting a big switch to list all the ioctl
> we known can safely pass, can grow the list when needed.
>From the above it should be obvious why such checking is entirely
unnecessary for the case of USB.
To be sure, one can write a driver which looks _inside_ the passed
*buf, and interpret the contents as a bunch of user pointers, in a
misguided attempt to create a DIY s/g capability, for instance.
If such a thing happens, we'd only have to identify the programmers
and impale them on a pole, then feed their intestines to crows.
That ought to take care of the problem without any checking lists.
-- Pete
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
