linux-kernel - Re: [RFC] printk/sysrq: Don't play with console

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]

Date:   Tue, 28 May 2019 19:15:43 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Dmitry Safonov <dima@...sta.com>, linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>, Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [RFC] printk/sysrq: Don't play with console_loglevel

On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit printk
>> context information. But doesn't such attempt resemble find_printk_buffer() ?
> 
> Adding KERN_UNSUPPRESSED to all printks down the op_p->handler()
> line is hardly possible. At the same time I'd really prefer not
> to have buffering for sysrq.

I don't think it is hardly possible. And I really prefer having
deferred printing for SysRq.

SysRq is triggered by writing to /proc/sysrq-trigger or typing special keys
on the keyboard. This means that SysRq can be triggered by administrator's
will, and SysRq can be repeated/retried by administrator's will. Therefore,
allowing SysRq-t to write to consoles after leaving the atomic context is
an improvement. My proposal allows deferred printing for SysRq, dump_header()
and warn_alloc(). We can try to wake up console_writer kernel thread upon
leaving the atomic context. If the kernel is unhealthy enough to make
console_writer kernel thread defunctional, administrator can issue other
SysRq in order to forcibly write to consoles.

Is the attempt of making printk() completely asynchronous going to be resumed?
I think that "automatically asynchronous" won't be accepted, and I think that
at best "explicitly asynchronous" (by allowing the caller to explicitly say
it using printk() argument) is possible. (Maybe "asynchronous by default" and
"explicitly synchronous" is possible. But "explicitly synchronous" would be
told by using printk() argument rather than by implicit/global printk context
information...)

Anyway, forcing SysRq output to apply ignore_loglevel will be doable using
printk() argument.