> > 2. Reset should not mean disconnecting the other interfaces. The
> > properties internal to the drivers of the other interfaces should be
> > retained and restored. Suspend/resume is the correct model, not
> > disconnect/probe. Kicking off all drivers but restoring the altsettings
> > like we do is flat out wrong.
>
> Yes. Likewise there's a problem in the current driver
> probe logic ... drivers expect it's their responsibility
> to choose altsettings, but there's now code that sets
> the host-side record to every legal value (not the device!).
>
> I'd rather seee it formal: drivers own altsettings, usbcore
> leaves them alone except for when drivers change them. That'd
> apply for probes during reset() too, not just first-enumeration.
Yes.
> > 3. Usbfs is a security problem and needs filtering of control requests.
> > You can use it to set a device to an occupied address thereby crashing
> > any device.
>
> The issue is a general one with control requests. SET_ADDRESS is
> an interesting example, where pre-filtering ought to reject requests.
>
> But there are similar issues for SET_CONFIGURATION and SET_INTERFACE,
> both of which affect usbcore deeply enough to oops drivers that don't
> use the "approved" API calls.
OK. How about anything but vendor specific requests needing
CAP_SYS_HARDWARE ?
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
