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
