linux-kernel - Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

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: <58896EFF.7030900@linux.intel.com>
Date:   Thu, 26 Jan 2017 11:37:35 +0800
From:   Lu Baolu <baolu.lu@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, tglx@...utronix.de,
        linux-usb@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, Jiri Slaby <jslaby@...e.cz>
Subject: Re: [PATCH v5 1/4] usb: dbc: early driver for xhci debug capability

Hi,

On 01/26/2017 12:16 AM, Peter Zijlstra wrote:
> On Wed, Jan 25, 2017 at 11:51:34PM +0800, Lu Baolu wrote:
>
>>> What is timeout and why?
>> Put it in simple:
>>
>> The driver sets the RUN bit in control register and polls READY
>> bit in status register for the successful USB device enumeration.
>> As the USB device enumeration might fail and the READY bit will
>> never be set, the driver must have a timeout logic to avoid
>> endless loop.
>>
>> More details:
>>
>> The operational model is that driver sets up all necessary registers
>> and data structures, and then starts the debug engine by setting
>> the RUN/STOP bit in the control register.
>>
>> The debug engine then brings up itself as a ready-for-enumeration
>> USB device. The USB link between host and device starts link training
>> and then host will detect the connected device. The hub driver in
>> host will then starts the USB device enumeration processes (as defined
>> in USB spec). If everything goes smoothly, the device gets enumerated
>> and host can talk with the debug device.
>>
>> After that, xdbc firmware will set the READY bit in status register. And
>> the driver can go ahead with data transfer over USB.
> I have vague memories from a prior discussion where you said this READY
> state can be lost at any time (cable unplug or whatnot) and at that
> point the driver should re-start the setup, right?

Yes. So the documentation requires users not to unplug the usb
cable during debugging. This rule applies to other debug methods
as well.

>
>>>  If there is an error other than !ready, I would
>>> expect the hardware to inform you of this through another status bit,
>>> no?
>> Yeah, this might be another choice of hardware design. But it's not a
>> topic for this driver.
> So is there really no way to way to distinguish between "I did setup and
> am waiting for READY", "I did setup, am waiting for READY, but things
> got hosed" and "I was READY, things be hosed" ?
>
> I suppose the first and last can be distinguished by remembering if you
> ever saw READY, but the first and second are the interesting case I
> think.
>
>>> So why can't you poll indefinitely for either ready or error?
>>>
>> Even if the hardware has both ready and error status bits, it's still
>> nice to have a time out watch dog. Buggy hardware or firmware
>> might not set any of these bits. Polling indefinitely might result in
>> a endless loop.
> Loosing output, esp. without indication, is very _very_ annoying when
> you're debugging things. Its just about on par with a stuck system, at
> least then you know something bad happened.

Fair enough.

USB connection is stable enough, unless the user unplugs the
USB cable during debugging.

Best regards,
Lu Baolu