linux-kernel - Re: [RFC PATCH v4 9/9] printk: use a new ringbuffer implementation

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, 8 Aug 2019 20:48:41 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     John Ogness <john.ogness@...utronix.de>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrea Parri <andrea.parri@...rulasolutions.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>
Subject: Re: [RFC PATCH v4 9/9] printk: use a new ringbuffer implementation

On Thu, 8 Aug 2019 17:21:09 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> But laptops don't have reset buttons. They have "press the power
> button for ten seconds, power turns off. Press it again, and power
> comes on" reset sequences.

I've never tried, but are you saying that even with the "10 second
hold" the laptop's DRAM may still have old data that is accessible?

> 
> They are nasty to debug when they happen on a developer machine (I
> should know, I've definitely had them), but when they happen in the
> wild they are basically "user just rebooted the machine". End of
> story, and no stats or anything like that.

Would a best effort 1 page buffer work? Really, with a hard hang we
usually only care about the last thing that was printed (we need to add
one of those: stop printing after the first WARN_ON is hit, to not
lose the initial bug).

That way you could have a buffer that is written to constantly but only
is the size of one or two pages. It can have a variable in it that gets
reset on shutdown. If the system hangs, the next boot could look to see
if that page was shutdown cleanly (or never initialized) otherwise, it
can read the page or pages into a buffer that can be read from debugfs.

A user space tool could read this page and if it detects that it
contains data from a crash, notify the user and say "Can you send this
to linux-kernel@...r.kernel.org"? Even better if it tells the user the
subject and content of the email that should be sent.

-- Steve