linux-kernel - RE: [PATCH] x86: Avoid pr_cont() in show

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: <cbb4e190f9de45cf8586c1df02ec3619@AcuMS.aculab.com>
Date:   Tue, 10 Jul 2018 16:51:53 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Josh Poimboeuf' <jpoimboe@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>
CC:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Ingo Molnar <mingo@...nel.org>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Andy Lutomirski" <luto@...capital.net>,
        Borislav Petkov <bp@...e.de>,
        "Linus Torvalds" <torvalds@...ux-foundation.org>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: RE: [PATCH] x86: Avoid pr_cont() in show_opcodes()

From: Josh Poimboeuf
> Sent: 09 July 2018 20:12
> On Mon, Jul 09, 2018 at 10:49:53AM +0200, Peter Zijlstra wrote:
> > On Sat, Jul 07, 2018 at 10:54:28PM +0900, Tetsuo Handa wrote:
> > > >> Since syzbot is confused by concurrent printk() messages [1],
> > > >> this patch changes show_opcodes() to use snprintf().
> >
> > But how big of a problem is that really? We can't very well remove all
> > pr_cont stuff from the kernel.
> 
> I'd say we should try to make oopses as legible as possible.

To make oopses legible you need to lock the output between output lines.
Which would require a 'KERN_CONTINUED' marker on the previous print.

> Also KERN_CONT is inherently broken, and we should avoid using it in
> general, IMO.

I'm sure something semi-automatic could be done to expect a further
print if the line doesn't end in '\n'.
A per-cpu line buffer is probably excessive, but some kind of
timing out lock might work (release expecting re-acquire).

	David