On Mon, Nov 07, 2011 at 03:53:59PM -0500, Alan Stern wrote: > On Mon, 7 Nov 2011, Sarah Sharp wrote: > > > > > Alan, won't this global limit on the usbfs URB buffer size effect > > > > userspace drivers that are currently allocating large amounts of > > > > buffers, but still respecting individual buffer limit of 16KB? It seems > > > > like the patch has the potential to break userspace drivers. > > > > > > It might indeed. A further enhancement would replace that 16-MB global > > > constant with a sysfs attribute (a writable module parameter for > > > usbcore). Do you have any better suggestions? > > > > No, I don't have any better suggestions, except take out the limit. ;) > > > > I do understand why we don't want userspace to DoS the system by using > > up too much DMA'able memory. However, as I understand it, the usbfs > > files are created by udev with root access only by default, and distros > > may choose to install rules that have more permissive privileges. A > > device vendor may not be ensured that a udev rule with permissive access > > will be present for their device, so I think they're likely to write > > programs that require root access. Or require root privileges to > > install said udev rule. > > > > At that point, the same userspace program that has root privileges in > > order to access usbfs or create the udev rule can just load and unload > > the usbcore module with an arbitrarily large global limit, and the > > global limit doesn't really add any security. So why add the extra > > barrier? > > This is a question of kernel policy, and I don't know what is the > generally accepted approach to this sort of thing. Maybe Greg or Alan > Cox can comment. You have to set the limit to something, otherwise a non-root user can kill the box quite easily. If the admin wants to set the system up so that any user can use up all of the memory, they are free to do that, but we can't have it be the default. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
