linux-kernel - Re: [PATCH v4] panic: Avoid the extra noise dmesg

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: <20181211083230.x6s44wsgfgijl4ws@pathway.suse.cz>
Date:   Tue, 11 Dec 2018 09:32:30 +0100
From:   Petr Mladek <pmladek@...e.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Feng Tang <feng.tang@...el.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...e.de>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Sasha Levin <sashal@...nel.org>, stable@...nel.org
Subject: Re: [PATCH v4] panic: Avoid the extra noise dmesg

On Mon 2018-12-10 10:49:22, Kees Cook wrote:
> On Mon, Dec 10, 2018 at 10:17 AM Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > On Fri,  7 Dec 2018 17:51:19 +0800
> > Feng Tang <feng.tang@...el.com> wrote:
> >
> > > When kernel panic happens, it will first print the panic call stack,
> > > then the ending msg like:
> > >
> > > [   35.743249] ---[ end Kernel panic - not syncing: Fatal exception
> > > [   35.749975] ------------[ cut here ]------------
> > >
> > > The above message are very useful for debugging.
> > >
> > > But if system is configured to not reboot on panic, say the "panic_timeout"
> > > parameter equals 0, it will likely print out many noisy message like
> > > WARN() call stack for each and every CPU except the panic one, messages
> > > like below:
> >
> >
> > > Keeping the interrupt disabled will avoid the noisy message.
> > >
> > > When code runs to this point, it means user has chosed to not reboot, or
> > > do any special handling by using the panic notifier method, the only reason
> > > to enable the interrupt may be sysrq migic key and panic_blink function
> > > (though may not work even with irq enabled).
> > >
> > > So make the irq disabled by default and add a cmdline parameter
> > > "panic_keep_irq_on" to turn it on when needed.
> > >
> > > Signed-off-by: Feng Tang <feng.tang@...el.com>
> > >
> >
> > Acked-by: Steven Rostedt (VMware) <rostedt@...dmis.org>
> 
> I'm fine with the new boot param, but I think we need to leave it how
> it was by default: systems that want to see the blinking aren't going
> to have a screen to read about what boot param they need to add.
> Currently, we'll blink and spew extra warnings. With this patch we'll
> not blink and not spew: a headless machine will have no indication
> that a panic happened.

Just to be sure, in case, you did not follow the other long
discussion.

I had an alternative approach to switch printk() into nop at
this panic() stage. It can be restored when sysrq is triggered.
This approach allows to keep blinking and sysrq working. People
debugging the blinking would need to block this change but it
should be rare.

I do not resist on my solution. It looks a bit hacky. But it
is simple and rather straightforward.

Best Regards,
Petr