Hi, Binyamin Sharet <s.binyamin@xxxxxxxxx> writes: >> Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> writes: >>>> I'm using GadgetFs for USB host fuzzing (using umap2), >>>> and part of the fuzzing session is to send invalid descriptors at >>>> various stages. >>>> >>>> However, some requests are not delegated to user-land (see gadgetfs_setup() >>>> in gadget/legacy/inode.c), >>>> Specifically - GET_DESCRIPTOR (device/configuration) and SET_CONFIGURATION. >> >> that's because they don't have to be. Kernel caches the descriptors you >> write during gadgetfs initialization and just returns >> that. >> > > As I see it, there are at least two issues with that: > 1. gadgetfs can't handle complex, valid descriptor, such as Class > Specific descriptors, > this means that I can't emulate audio devices for example. why not? The first thing you do when you start out your gadgetfs daemon is write descriptors which kernel will use. Just write *all* descriptors you need. > 2. At least in my case, where I wan't to use gadgetfs for fuzzing > other USB hosts, I > can't really fuzz various stages of the enumeration phase, > specifically in the case of > descriptors that are usually requested at least twice (e.g. > configuration descriptor) you are not allowed to change your descriptors on the fly. Descriptors are static. Configuration descriptor is requested twice for a simple reason: Host doesn't know how big a configuration you have; so it asks only for the first 9 bytes which will contain bLength. Then host uses bLength to figure how big is your configuration and subsequently fetches the entire thing. >>>> Does a patch to switch the gadgetfs module to "delegate all" sounds reasonable? >>>> If so - what's the preferred way to do it? I have a few options in mind: >>> >>> Why do you need to delegate Get-Descriptor? The contents of the >>> response are entirely dictated by the descriptors provided by the user >>> program in the first place. >>> >>> Set-Configuration _is_ delegated to the user program, although the >>> program is not allowed to fail the request. Is that what you want to >>> do? >>> >>>> - module parameter >>>> - write some command to the ep0 file >>>> - send an ioctl to the ep0 file >>>> >>>> Any other suggestion? >>> >>> I suspect this sort of thing would not be accepted. If Felipe agrees, >>> you might as well just keep your changes out-of-tree. >> >> This will just open up a can of worms, I'm afraid. What we have today >> can even pass all USBCV tests, we're not breaking that, sorry. >> > > I get your point, what I propose is not to change the default behavior > of gadgetfs, > but allow it to enter to a special mode by the user. I am aware of the > issues that it > might raise, and understand your concerns. However, I am asking about > modifications in a specific, contained context. I would prefer to have it in the > mainline kernel, but if you don't think it fits - I will keep those > changes as an > out-of-tree module. you're gonna have a really hard time getting anything in mainline without explaining your goal. All you said is: "I wanna do fuzzying", but fuzzying of what exactly? Why do you need to fuzz during enumeration? This makes no sense. Gadgets are _not_ allowed to change their descriptors and kernel doesn't allow userspace to do that. If you wanna change your descriptor, then you _must_ disconnect from the host and write brand new descriptors during gadgetfs initialization. -- balbi
Attachment:
signature.asc
Description: PGP signature
