linux-kernel - Re: [syzbot? printk?] no WARN_ON() messages printed before "Kernel panic

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: <20190316144051.GB10815@tigerII.localdomain>
Date:   Sat, 16 Mar 2019 23:40:51 +0900
From:   Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        LKML <linux-kernel@...r.kernel.org>,
        syzkaller <syzkaller@...glegroups.com>,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [syzbot? printk?] no WARN_ON() messages printed before "Kernel
 panic - not syncing: panic_on_warn set ..."

On (03/16/19 15:16), Dmitry Vyukov wrote:
> > Hmm... sysctl, may be?
> >
> > > > I figured out that we should restrict it from doing
> > > > syslog(SYSLOG_ACTION_CONSOLE_OFF). And I also restricted its access o
> > > > /dev/console. But maybe there is something else? It _should_ not be
> > > > able to write to random sysctl's.
> > >
> > > Maybe try running with "ignore_loglevel" kernel command line option added?
> >
> > Right, that's something I would expect 0-day and syzkaller to do.
> 
> to double-check: enabling this won't lead to verbose/debug level of logging?

My bad, Saturday night.

You are right, this will make it very verbose. May be we can set
ignore_loglevel when we set loglevel to CONSOLE_LOGLEVEL_MOTORMOUTH.


Technically, we can have something like this

	CPU0						CPU1

	foo()						panic
	loglevel_save = console_loglevel
	....						console_verbose()
	console_loglevel = ABC
	....
	console_loglevel = loglevel_save		smp_send_stop()
	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	killed
							console_flush_on_panic()
							// console is
							// NOT verbose


So we either can set ignore_loglevel in console_verbose(). Or call
call console_verbose() one more time, once we stopped other CPUs
and before we console_flush_on_panic().

---

diff --git a/kernel/panic.c b/kernel/panic.c
index 0ae0d7332f12..11784d37f625 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -263,6 +263,7 @@ void panic(const char *fmt, ...)
 	if (_crash_kexec_post_notifiers)
 		__crash_kexec(NULL);
 
+	console_verbose();
 #ifdef CONFIG_VT
 	unblank_screen();
 #endif

---

But I think that setting ignore_loglevel in console_verbose() is more
reliable.

	-ss