linux-kernel - RE: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for quirky xHCs

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: <A2CA0424C0A6F04399FB9E1CD98E0304844BF057@US01WEMBX2.internal.synopsys.com>
Date:	Thu, 17 Jul 2014 19:10:53 +0000
From:	Paul Zimmerman <Paul.Zimmerman@...opsys.com>
To:	Maciej Puzio <mx34567@...il.com>,
	Julius Werner <jwerner@...omium.org>
CC:	Mathias Nyman <mathias.nyman@...el.com>,
	David Laight <David.Laight@...lab.com>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	"Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] usb: xhci: Fix Set TR Dequeue Pointer cycle state for
 quirky xHCs

> From: linux-usb-owner@...r.kernel.org [mailto:linux-usb-owner@...r.kernel.org] On Behalf Of Maciej Puzio
> Sent: Thursday, July 17, 2014 11:25 AM
> 
> Tested-by: Maciej Puzio <mx34567@...il.com>
> 
> On Tue, Jul 8, 2014 at 2:01 PM, Julius Werner <jwerner@...omium.org> wrote:
> > Commit 1f81b6d22 "usb: xhci: Prefer endpoint context dequeue pointer
> > over stopped_trb" changed the logic in xhci_find_new_dequeue_state() to
> > only use the Endpoint Context's TR Dequeue Pointer instead of the last
> > Event TRB's TRB Pointer as a basis from which to infer the host
> > controller state. This has uncovered a bug with certain Asmedia xHCs
> > which seem to advance their TR Dequeue Pointer one TRB behind the one
> > that caused a Stall Error.
> >
> > This confuses the cycle state calculation since cur_td->last_trb is now
> > behind hw_dequeue (which the algorithm interprets as a single huge TD
> > that wraps around the whole transfer ring). This patch counteracts that
> > by explicitly looking for last_trb when searching for hw_dequeue from
> > the old software dequeue pointer. If it is found, we toggle the cycle
> > state once more to balance out the incorrect toggle that will happen
> > later.
> >
> > In order to make this work for both single and multi segment rings, this
> > patch also expands the detection of wrap-around TDs to work on the
> > latter ones (which cannot normally happen because the kernel prevents
> > that case to allow for ring expansion, but it's how things appear to be
> > in the quirky case and allowing the code to handle it makes it easier to
> > generalize this fix across all kernels). The code will now toggle the
> > cycle state whenever last_trb is before hw_dequeue on the same segment,
> > regardless of how many segments there are in the ring.
> >
> > This patch should be backported to kernels as old as 2.6.31 that contain
> > the commit ae636747146ea97efa18e04576acd3416e2514f5 "USB: xhci: URB
> > cancellation support."
> >
> > Cc: stable@...r.kernel.org
> > Signed-off-by: Julius Werner <jwerner@...omium.org>
> > ---
> >  drivers/usb/host/xhci-ring.c | 18 +++++++++++++-----
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
> > index 749fc68..50abc68 100644
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -489,8 +489,17 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
> >         /* Find virtual address and segment of hardware dequeue pointer */
> >         state->new_deq_seg = ep_ring->deq_seg;
> >         state->new_deq_ptr = ep_ring->dequeue;
> > +       state->new_cycle_state = hw_dequeue & 0x1;
> >         while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
> >                         != (dma_addr_t)(hw_dequeue & ~0xf)) {
> > +               /*
> > +                * Quirky HCs can advance hw_dequeue behind cur_td->last_trb.
> > +                * That violates the assumptions of the TD wrap around check
> > +                * below, so toggle the cycle state once more to cancel it out.
> > +                */
> > +               if (state->new_deq_ptr == cur_td->last_trb)
> > +                       state->new_cycle_state ^= 1;
> > +
> >                 next_trb(xhci, ep_ring, &state->new_deq_seg,
> >                                         &state->new_deq_ptr);
> >                 if (state->new_deq_ptr == ep_ring->dequeue) {
> > @@ -500,12 +509,11 @@ void xhci_find_new_dequeue_state(struct xhci_hcd *xhci,
> >         }
> >         /*
> >          * Find cycle state for last_trb, starting at old cycle state of
> > -        * hw_dequeue. If there is only one segment ring, find_trb_seg() will
> > -        * return immediately and cannot toggle the cycle state if this search
> > -        * wraps around, so add one more toggle manually in that case.
> > +        * hw_dequeue. If last_trb is on the current segment before hw_dequeue,
> > +        * that means we wrap around the whole ring, but find_trb_seq() will
> > +        * return immediately. Toggle the cycle state manually in that case.
> >          */
> > -       state->new_cycle_state = hw_dequeue & 0x1;
> > -       if (ep_ring->first_seg == ep_ring->first_seg->next &&
> > +       if (state->new_deq_seg->trbs < cur_td->last_trb &&
> >                         cur_td->last_trb < state->new_deq_ptr)
> >                 state->new_cycle_state ^= 0x1;
> >
> > --
> > 1.8.3.2

Hmm. Wouldn't it be safer to have a quirk for this, and only enable
the workaround if the Asmedia controller is detected? This code is so
complicated that it is difficult to see whether this could have a
harmful effect on controllers without the bug.

-- 
Paul