linux-kernel - Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

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] [day] [month] [year] [list]

Date:	Wed, 18 Nov 2015 19:10:43 +0800
From:	Lu Baolu <baolu.lu@...ux.intel.com>
To:	Dmitry Malkin <DMalkin@...ecurity.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc
 quirk

Hi,

On 11/17/2015 06:28 PM, Dmitry Malkin wrote:
> On Mon, 16 Nov 2015 10:18:42 +0800, Lu Baolu wrote:
>> This quirk works as well if debug host doesn't have DBC. I didn't try a
>> DBC-capable debug host yet.
> Hi,
>
> I went through it again, with your v3 patch series on top of vanilla v4.3.0.
>
> Two targets, one host, all with Intel chipset (XHCI device 0:14.0 with VID:8086).
> Targets DIDs are 9c31 (8-series chipset) and 9d2f (100-series chipset).
> Host DID is 8c31 (8-series).
>
> I can only further confirm my previous observations.  The host cannot
> see the target (there is no debug device) at all, until I manually
> re-plug a debug cable.  Cable plugged in, prior to starting the target.

Thank you for your time.

Are you using a "USB3 debugging cable"? The internal wiring of
the debug cable is crossed over.

> I think that trying a Hot Reset for all disconnected USB 3.0 ports on
> the debug target *just before* setting DCE bit is inherently racy.
>
> What if the number of disconnected ports changes or if someone will insert
> a print statement or refactors your code?

That might be problematic. I will put a comment there.

>
> Also sending TS2 to the debug host port will either:
>   - get dropped by its hub as unsupported upstream request, or
>   - get ignored due to SS.Inactive port state
>
> Could you explain what exactly you workaround does at the low level?

What I though was that reset USB 3.0 ports on debug target before setting
DCE bit will cause debug host to warm reset the port for enumeration
purpose and then setting the DCE bit will take effect.

This just works on my development machine, not only connecting debug
target to root port of host, but also under external hubs. I realized that
this quirk isn't a universal solution and it might not work with some
silicons. But I thought it shouldn't do any harmless. In bad case, users
could plug out and plug in the debug cable, or reset the port through
the sysfs node for workaround. If this is acceptable, I will add this in
the user guide and increase the timeout value in code.

Thanks,
-Baolu

>
> --
> with best regards,
> Dmitry Malkin
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/