linux-kernel - Re: dwc3: unusual handling of setup requests with wLength == 0

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: <61cf24db-9dbb-4bf3-aafe-d515fc37cca8@rowland.harvard.edu>
Date:   Wed, 30 Aug 2023 10:48:02 -0400
From:   Alan Stern <stern@...land.harvard.edu>
To:     Thinh Nguyen <Thinh.Nguyen@...opsys.com>
Cc:     Andrey Konovalov <andreyknvl@...il.com>,
        Felipe Balbi <balbi@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB list <linux-usb@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: dwc3: unusual handling of setup requests with wLength == 0

On Wed, Aug 30, 2023 at 01:32:28AM +0000, Thinh Nguyen wrote:
> That reminds me another thing, if the host (xhci in this case) does a
> hard reset to the endpoint, it also resets the TRB pointer with dequeue
> ep command. So, the transfer should not resume. It needs to be
> cancelled. This xHCI behavior is the same for Windows and Linux.

That's on the host side, right?  How does this affect the gadget side?

That is, cancelling a transfer on the host doesn't necessarily mean it 
has to be cancelled on the gadget.  Does it have any implications at all 
for the gadget driver?

> > I think it should be the opposite; the class protocol should specify
> > how to recover from errors.  If for no other reason then to avoid the
> > data duplication problem for USB-2.  However, if it doesn't specify a
> > recovery procedure then there's not much else you can do.
> 
> Right, unfortunately that's not always the case that class protocol
> spell out how to handle transaction error.

All too true...

> > But regardless, how can the gadget driver make any use of the
> > knowledge that the UDC received a Clear-Halt?  What would it do
> > differently?  If the intent is simply to clear an error condition and
> > continue with the existing transfer, the gadget driver doesn't need to
> > do anything.
> 
> It's not simple to clear an error. It is to notify the gadget driver to
> cancel the active transfer and resync with the host.

How does the gadget driver sync with the host if the class protocol 
doesn't say what should be done?

Also, what if there is no active transfer?  That is, what if the 
transaction that got an error on the host appeared to be successful on 
the gadget and it was the last transaction in the final transfer queued 
for the endpoint?  How would the UDC driver notify the gadget driver in 
this situation?

>  This is observed in
> UASP driver in Windows and how various consumer UASP devices handle it.

I don't understand what you're saying here.  How can you observe whether 
a transfer is cancelled in a consumer UAS device?  And how does the 
consumer device resync with the host?

> There no eqivalent of Bulk-Only Mass Storage Reset request from the
> class protocol. We still have the USB analyzer traces for this.

Can you post an example?  Not necessarily in complete detail, but enough 
so that we can see what's going on.

> Regardless whether the class protocol spells out how to handle the
> transaction error, if there's transaction error, the host may send
> CLEAR_FEATURE(halt_ep) as observed in Windows. The gadget driver needs
> to know about it to cancel the active transfer and resync with the host.

I'll be able to understand this better after seeing an example.  Do you 
have any traces that were made for a High-speed connection (say, using 
a USB-2 cable)?  It would probably be easier to follow than a SuperSpeed 
example.

Alan Stern