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

Message-ID: <1447428842332.88038@ptsecurity.com>
Date:	Fri, 13 Nov 2015 15:34:02 +0000
From:	Dmitry Malkin <DMalkin@...ecurity.com>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
CC:	"baolu.lu@...ux.intel.com" <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH v3 04/12] usb: xhci: dbc: add support for Intel xHCI dbc
 quirk

On Mon, 9 Nov 2015 15:38:33 +0800, Lu Baolu wrote:
> On Intel platform, if the debug target is connected with debug
> host, enabling DCE bit in command register leads to a hung bus
> state. In the hung state, the host system will not see a port
> connected status bit set. Hence debug target fails to be probed.
>
> The state could be resolved by performing a port reset to the
> debug port from the host xHCI. This patch introduces this work
> around.

Is it correct to call this a "hung bus state"?  Wouldn't calling it
"hung port state" more appropriate?

I have observed this DCE-enable-related hung port state,
but the reason seemed to be different in my case:

Citing a note (sic!) from The Holy XHCI Spec, section 7.6.4.1:
> If a Debug Host attempts to attach to a Debug Target before the DCE flag is set,
> both ends of the link shall transition to the Inactive state.
> So a Debug Host should periodically issue a Warm Reset
> to ports that are Inactive to enable a connection to the DbC of the Debug Target.

Indeed, the inactive state is what I have observed (PLS field of port register PORTSC)
when the DCE bit is set to 1 with the cable already plugged in.

Now, according to my interpretation of The Hole USB 3.1 spec, section 7.5.2,
which says:
> eSS.Inactive is a state where a link has failed Enhanced SuperSpeed operation.
> A downstream port can only exit from this state when directed, or upon detection of
> an absence of a far-end receiver termination (R RX-DC ) specified in Table 6-21,
> or upon a Warm Reset.

It follows, that since hosts without DBC cannot listen to upstream requests,
the debug target-originated port reset requests (both hot and warm) will be ignored
by the debug host.

This is the essence of the "hung port state" that I was able to observe.

Note, that this roadblock doesn't appear if you attach the cable /after/ enabling the DCE bit,
or, alternatively, if the host has DBC.

And indeed, your quirk will work in the latter case, since the debug host hub
will be able to see the upstream reset request.

--
with best regards,
Dmitry Malkin
--
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/