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]

Message-ID: <CAHk-=wgTEs7AFTxQPsqpHS1JN9OU1eiY6eCdFjxnKSU_1POx=g@mail.gmail.com>
Date:   Fri, 9 Aug 2019 13:20:50 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        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>,
        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 Fri, Aug 9, 2019 at 1:07 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
> I'm all for it. I just tried it out and the ratio was 3 out of 5 retained
> the data +/- a few bitflips with ~2 seconds power off. The other two were
> the laptop and that server machine which wipes everything.

Perfect. That actually says "the theory works". My desktop worked only
on warm reboot - which isn't really the interesting case (it does
cover things like triple boots etc and "press reset button when it
hangs, so it *can* be helpful, but even on desktops reset buttons seem
to be getting less common).

But yes, the whole thing where BIOSes wipe everything is problematic,
but that's where I just need to ping the right people inside Intel
again.

I did send the patch to inside Intel earlier, but I think the timing
for that might have been bad (people were on vacation), so I should
just reach out to more Intel people.

It would be better to have a more polished patch (the whole "fixed
address at around 12GB physical" really is such a horrible hack), but
I dreaded actually parsing the e280 memory map to do some "static for
one particular configuration" thing.

I should just do that and have something that Intel HW and FW people
can test on any hardware.

> If that can be avoided with some ACPI tweak especially on the laptop, that
> would be great. I'm not so worried about the server case.

Yeah, the server case I think we have covered other ways. Plus people
running them tend to have serious developer resources anyway.

They might still use something like this for some convenient
first-order debugging if we end up having generally available, of
course, but the target really is "random laptop or home user that uses
a distro and can't be expected to even try to sanely report - much
less debug - a hung machine condition".

                     Linus