On Fri, Nov 15, 2019 at 05:10:26PM +0100, Andrey Konovalov wrote: > On Fri, Nov 15, 2019 at 4:44 PM Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > > > On Fri, 15 Nov 2019, Andrey Konovalov wrote: > > > > > Hi Greg and Alan, > > > > > > For USB fuzzing it would be nice to be able to export usb_device_id > > > structs from the kernel to facilitate the fuzzer with generating USB > > > descriptors that match to actual drivers. The same is required for > > > hid_device_id structs, since those are matched separately by the > > > usbhid driver (are there other cases like this?). > > > > > > Currently I have a hacky patch [1] that walks all drivers for USB and > > > HID buses and then prints all device ids for those drivers into the > > > kernel log. Those are manually parsed and built into the fuzzer [2] > > > and then used to generate USB descriptors [3]. > > > > There are so many different flags for those id structures, parsing and > > understanding them must be quite difficult. > > > > > I'm thinking of making a proper patch that will add a debugfs entry > > > like usb/drivers (and usb/hid_drivers?), that can be read to get > > > USB/HID device ids for all loaded drivers. Would that be acceptable? > > > Or should I use some other interface to do that? > > > > I can't think of a better way to get the information from a running > > kernel. > > > > There is another possibility, though. If the drivers are built as > > modules, the information is already available to userspace tools via > > depmod. You could get it from the modules.dep.bin file. This has the > > advantage that it will work even for drivers that aren't currently > > loaded. > > This is the same thing Greg mentions above, right? Yes. > Would this work for drivers that are built into the kernel (as =y)? No, sorry. There has not been any need to export that information to userspace as nothing has ever needed that. The only reason we exported that at all was to allow modules to auto-load to handle the device. thanks, greg k-h
