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: <alpine.DEB.2.21.1908092141490.21433@nanos.tec.linutronix.de>
Date:   Fri, 9 Aug 2019 22:07:25 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
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, 9 Aug 2019, Linus Torvalds wrote:
> On Fri, Aug 9, 2019 at 4:15 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > >
> > > But I don't know what a power-off-in-laptop scenario really looks like..
> >
> > That's random behaviour. It's hardware & BIOS & value add. What do you
> > expect?
> >
> > I tried on a few machines. My laptop does not retain any useful information
> > and on some server box (which takes ages to boot) the memory is squeaky
> > clean, i.e. the BIOS wiped it already. Some others worked with a two second
> > delay between turning the remote power switch on and off.
> 
> You were there at the Intel meeting, weren't you?

Yup.

> This is all about the fact that "we're not getting sane and reliable
> debug facilities for remote debugging". We haven't gotten them over
> two decades, we're not seeing it in the future either.

I know. It sucks.

> So what if we _can_ get an ACPI update and in the next decade your
> laptop _will_ have a memory area that doesn't get scribbled over?

No argument here.

> Does it work today? Yes it does, but only for very special cases
> (basically warm reboot with "fast boot" enabled).
> 
> But they are special cases that may be things that can be extended
> upon without any actual hardware changes.

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.

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.

Debugging laptops and random client machines is the real interesting use
case. They usually lack serial and even if they have serial then the
reporter has not necessarily a second machine to capture the stuff.

Thanks,

	tglx