Re: Testing endpoint halt support for raw-gadget

[Andrey Konovalov <andreyknvl@google.com>]

On Wed, May 13, 2020 at 9:09 PM Alan Stern <stern@rowland.harvard.edu> wrote:
>
> On Wed, May 13, 2020 at 08:31:35PM +0200, Andrey Konovalov wrote:
> > On Wed, May 13, 2020 at 8:14 PM Alan Stern <stern@rowland.harvard.edu> wrote:
> > >
> > > On Wed, May 13, 2020 at 07:07:20PM +0200, Andrey Konovalov wrote:
> > > > Hi Alan,
> > > >
> > > > I've been looking at this a little more. Do I understand correctly
> > > > that even though Dummy UDC names endpoints as "ep1in", etc. it
> > > > actually allows to assign endpoints addresses different from what is
> > > > specified in the endpoint names (it uses find_endpoint() to find the
> > > > right endpoint based on ep->desc)? E.g. you can technically assign
> > > > endpoint with address 2 (| USB_DIR_IN) to "ep1in".
> > >
> > > Yes, that's right.  In fact, you can do this with any UDC.  (But with
> > > other UDCs it won't work, whereas with dummy-hcd it will.)
> > >
> > > > If this is correct, this kind of limits Dummy UDC usage with Raw
> > > > Gadget the way it is currently implemented, as Raw Gadget assumes that
> > > > the endpoint address must be fixed when the endpoint is named as
> > > > ep1in.
> > >
> > > Okay.  That makes sense, since it is true for most UDCs.
> > >
> > > > Would it be acceptable to add another mode to Dummy UDC that names the
> > > > endpoints as "ep-a"? Perhaps enabled with a module parameter. I'm not
> > > > sure if this kind of naming would be technically correct, as "ep-a"
> > > > name assumes that we can assign arbitrary transfer type to the
> > > > endpoint as well, which isn't possible with Dummy UDC, as it doesn't
> > > > support ISO transfers.
> > > >
> > > > Or do you think there can be another way to expose the fact that Dummy
> > > > UDC allows arbitrary addresses? I could hardcode this into Raw Gadget,
> > > > but it doesn't feel like the right approach.
> > >
> > > Why do you want to do this?  Does anything go wrong if you just continue
> > > to assume the endpoint numbers are fixed?
> >
> > Yes. Some USB drivers require endpoints with certain logical functions
> > to have certain addresses (e.g. for ath9k: [1]). This limits the
> > ability to use Raw Gadget + Dummy UDC for fuzzing, as sometimes we
> > can't emulate such devices unless Dummy UDC endpoint with a particular
> > address has required capabilities to implement those logical functions
> > (e.g. for ath9k: we can't emulate USB_REG_IN_PIPE endpoint, as Dummy
> > UDC only has an OUT endpoint with address 3).
> >
> > It's acceptable to be unable to emulate such devices with real UDCs
> > with fixed address endpoints, but it would be highly desirable to be
> > able to do that with Dummy UDC, as it technically supports
> > configurable endpoint addresses.
>
> Okay, that's reasonable.
>
> > [1] https://elixir.bootlin.com/linux/v5.6.12/source/drivers/net/wireless/ath/ath9k/hif_usb.h#L68
> >
> > > I suppose, if you thought this was really necessary, we could change
> > > find_endpoint() so that it looks for a match against the endpoint's name
> > > instead of against the address stored in the descriptor.
> >
> > That would make the behaviour of Dummy UDC match what is expected from
> > it based on the endpoint names, but won't help with the problem
> > described above.
>
> Would you want to do this anyway?  It doesn't seem necessary to me.

No, no need for this :)

>
> > > Or we could
> > > change the last thirteen "generic" endpoints in ep_info[] to be
> > > configurable: "ep-a", ..., "ep-m", or "ep-aout", ..., "ep-min".  (The
> > > fact that the endpoints don't support isochronous is exposed through the
> > > usb_ep_caps structures.)
> >
> > I think this should work. If we put this under a module parameter,
> > then we can make all endpoints have configurable names.
>
> No need for a module parameter; just make it a permanent change to the
> driver.

I was thinking that it could break some existing users, but I don't
know for sure.

> Would you like to submit a patch?

Sure, will do. Thanks!