Hi Alan, On Thursday 23 September 2004 16:41, Alan Stern wrote: > On Thu, 23 Sep 2004, Duncan Sands wrote: > > > Hi Alan, my plan is to have a config option (CONFIG_USB_STRING_WORKAROUNDS) > > and a device black/white list. With the config option selected, there are > > three cases: > > > > (A) device in the blacklist. Strings with type and length both 0 give an > > error -EINVAL as now. > > (B) device in the whitelist. Scans the "string" for printable characters > > in the US plane. If it finds something of positive length, returns it, > > otherwise -EINVAL. > > (C) device not in black/whitelist. Scans as in (B), and if it finds a string > > of positive length, sends a message to the system log describing the string > > and the device, and suggests sending an email to the list. Returns -EINVAL. > > > > This is the most conservative setup, but maybe it is overkill. What do you > > think? > > I think it's overkill. Despite what I wrote before, that test patch you > sent out yesterday looked pretty good. Config options and blacklists > should be avoided if at all possible, especially for stupid little things > like this.
there is a small danger that some driver "explores" the string descriptors by seeing if usb_string returns something, hits a non-string that happens to return a descriptor with first two bytes zero followed by something that parses OK, and gets all confused. I'd say this is pretty unlikely. In any case, if the kernel prints a message then we'll soon hear if it happens. > When the string descriptor routines encounter a result that has both type > and length equal to 0, cautious scanning seems like a good way to proceed. > In other words, I like option (C) but not (A) or (B). And I would leave > out the part about suggesting an email to the list, since it's not needed > if no one is maintaining a black/whitelist. If I understand correctly, you suggest: if scanning finds something reasonable, print a message and return what was found. The only problem is technical: since printk only takes ASCII, the string needs to be transformed, meaning a new buffer is required... not very elegant, especially as usb_string does the same transformation later. Hmmm, maybe usb_string can do the printing; to know that something funny was going on it could check buf[0] and/or buf[1] just before doing the conversion and print a warning if it saw something weird. OK - patch in progress. Duncan. ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
