linux-kernel - Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87tvkttm2w.fsf@linux.intel.com>
Date:   Wed, 07 Nov 2018 08:53:43 +0200
From:   Felipe Balbi <balbi@...nel.org>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Paul Elder <paul.elder@...asonboard.com>,
        Bin Liu <b-liu@...com>, kieran.bingham@...asonboard.com,
        gregkh@...uxfoundation.org, USB list <linux-usb@...r.kernel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        rogerq@...com
Subject: Re: [PATCH 4/6] usb: gadget: add functions to signal udc driver to delay status stage


Hi,

Alan Stern <stern@...land.harvard.edu> writes:
>> Alan Stern <stern@...land.harvard.edu> writes:
>> > There's a similar race at the hardware level.  What happens if the
>> > controller receives a new SETUP packet and concurrently the driver is
>> > setting up the controller registers for a response to an earlier
>> > SETUP?  I don't know how real controllers handle this.
>> 
>> That's HW implementation detail. DWC3, for instance, will ignore the
>> TRBs and return me the status "setup packet pending". Then I just start
>> a new SETUP TRB.
>
> You mean the UDC hardware sets a "setup pending" flag in some register,
> and then ignores any attempts to do anything with ep0 until the driver
> clears this flag?

Yes, except that the "flag" is a status on the TRB itself (TRB is dwc3's
DMA transfer descriptor).

>> > You mean, should we allow function drivers to queue the data-stage
>> > request after the setup handler has returned?  I don't see any reason
>> 
>> that's already done:
>> 
>> static void dwc3_ep0_xfer_complete(struct dwc3 *dwc,
>> 			const struct dwc3_event_depevt *event)
>> {
>> 	struct dwc3_ep		*dep = dwc->eps[event->endpoint_number];
>> 
>> 	dep->flags &= ~DWC3_EP_TRANSFER_STARTED;
>> 	dep->resource_index = 0;
>> 	dwc->setup_packet_pending = false;
>> 
>> 	switch (dwc->ep0state) {
>> 	case EP0_SETUP_PHASE:
>> 		dwc3_ep0_inspect_setup(dwc, event);
>> 		break;
>> [...]
>> }
>
> ...
>
> You mean, it's already done in DWC3.  What about other UDC drivers?

if they're not implementing this possibility, then that's a bug on
those UDC drivers :)

>> > why not.  After all, some drivers may require this.  Likewise for the 
>> > data stage of a control-IN.
>> >
>> > Another thing we should do is give function drivers a way to send a
>> > STALL response for the status stage.  Currently there's no way to do
>> > it, if a data stage is present.
>> 
>> Status stage can only be stalled if host tries to move data on the wrong
>> direction.
>
> The USB-2 spec disagrees.  See Table 8-7 in section 8.5.3.1 and the
> following paragraphs.  (Although, I can't see why a function would ever
> fail to complete the command sequence for a control-IN transfer after
> the data had already been sent.)

I can't see how we could ever STALL after returning the data requested
by the host. Seems like that wasn't well thought out.

-- 
balbi

Download attachment "signature.asc" of type "application/pgp-signature" (833 bytes)