linux-kernel - Re: [PATCH v4 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, 10 Nov 2016 12:44:45 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Lu Baolu <baolu.lu@...ux.intel.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Mathias Nyman <mathias.nyman@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>, linux-usb@...r.kernel.org,
        x86@...nel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4 1/4] usb: dbc: early driver for xhci debug capability

On Thu, Nov 10, 2016 at 09:56:41AM +0100, Thomas Gleixner wrote:
> On Thu, 10 Nov 2016, Lu Baolu wrote:

> > This seems to be a common issue for all early printk drivers.
> 
> No. The other early printk drivers like serial do not have that problem as
> they simply do:
> 
>    while (*buf) {
>       while (inb(UART) & TX_BUSY)
>    	 cpu_relax();
>       outb(*buf++, UART);
>    }

Right, which is why actual UARTs rule. If only laptops still had pinouts
for them life would be sooooo much better.

Ideally the USB debug port would be a virtual UART and its interface as
simple and robust.

> The wait for the UART to become ready is independent of the context as it
> solely depends on the hardware.
> 
> As a result you can see the output from irq/nmi intermingled with the one
> from thread context, but that's the only problem they have.
> 
> The only thing you can do to make this work is to prevent printing in NMI
> context:
> 
> write()
> {
> 	if (in_nmi())
> 		return;
> 	
> 	raw_spinlock_irqsave(&lock, flags);
> 	....
> 
> That fully serializes the writes and just ignores NMI context printks. Not
> optimal, but I fear that's all you can do.

I would also suggest telling the hardware people they have designed
something near the brink of useless. If you cannot do random exception
context debugging (#DB, #NMI, #MCE etc..) then there's a whole host of
problems that simply cannot be debugged.

Also note that kdb runs from NMI context, so you'll not be able to
support that either.