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]

Date:   Thu, 26 Jan 2017 08:19:37 +0100
From:   Ingo Molnar <mingo@...nel.org>
To:     Lu Baolu <baolu.lu@...ux.intel.com>
Cc:     Peter Zijlstra <peterz@...radead.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

* Lu Baolu <baolu.lu@...ux.intel.com> wrote:

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

What does the hardware do in this case? The XHCI registers are in the host 
hardware, so they won't disappear, right? Is there some cable connection status 
bit we can extract without interrupts?

I.e. if there's any polling component then it would be reasonable to add an error 
component: poll the status and if it goes 'disconnected' then disable early-printk 
altogether in this case and trigger an emergency printk() so that there's chance 
that the user notices [if the system does not misbehave otherwise].

I.e. try to be as robust and informative as lockdep - yet don't lock up the host 
kernel: lockdep too is called from very deep internals, there are various 
conditions where it sees corrupt data structures (i.e. a 'disconnect' - a system 
environment outside the normal bounds of operation), yet of the kernel and over 
the last 10+ years of lockdep's existence we had very, very few cases of lockdep 
itself locking up and behaving unpredictably.

Thanks,

	Ingo