linux-kernel - Re: [PATCH] printk: Add loglevel for "do not print to consoles".

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: <a59271f1-b3fc-26d1-f0a2-5ec351d0095e@i-love.sakura.ne.jp>
Date:   Thu, 30 Apr 2020 01:35:04 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Michal Hocko <mhocko@...nel.org>
Cc:     Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
        Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".

On 2020/04/29 23:21, Michal Hocko wrote:
> I am trying to say that KERN_NO_CONSOLES resembles more a policy than a
> priority. Because I as a developer have no idea whether the message is
> good enough for console or not.

Right, KERN_NO_CONSOLES is not a priority.

> I believe we are free to change kernel log levels as we find a fit. I
> was not aware that KERN_DEBUG messages are automatically filtered out.

Below is the default rules for rsyslog-8.24.0-52.el7 (userspace syslog daemon).
Of course administrators can modify as needed, but notice that KERN_INFO is saved
to /var/log/messages but KERN_DEBUG is saved to nowhere.

----------
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*                                                 /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;authpriv.none;cron.none                /var/log/messages

# The authpriv file has restricted access.
authpriv.*                                              /var/log/secure

# Log all the mail messages in one place.
mail.*                                                  -/var/log/maillog

# Log cron stuff
cron.*                                                  /var/log/cron

# Everybody gets emergency messages
*.emerg                                                 :omusrmsg:*

# Save news errors of level crit and higher in a special file.
uucp,news.crit                                          /var/log/spooler

# Save boot messages also to boot.log
local7.*                                                /var/log/boot.log
----------

> Even if this is the case then this doesn't really disallow admins to
> allow KERN_DEBUG into log files. Dump of the oom eligible tasks is
> arguably a debugging output anyway. So I disagree with your statement.

If dump_tasks() were changed to use KERN_DEBUG, administrators have to add
"kern.debug" rule (at the same time endure a lot of noise from KERN_DEBUG)
in order to record OOM victim candidates for later analysis.

> 
>> If the kernel allows the former to use KERN_NO_CONSOLES in addition to KERN_INFO, the administrator can
>> select from two choices: printing "both the former and the latter" or "only the latter" to consoles.
> 
> I am not really familiar with all the possibilities admins have when
> setting filtering for different consoles but KERN_NO_CONSOLES sounds
> rather alien to the existing priority based approach.

KERN_NO_CONSOLES is not a priority based approach.
KERN_NO_CONSOLES resembles CONSOLE_LOGLEVEL_SILENT.

>                                                       You can fine tune
> priorities and that is all right because they should be reflecting
> importance.

Developer's importance and administrator's interests are different. Any printk()
user is randomly selecting KERN_$LEVEL. Administrators are swayed by having to
record the lowest priority from all interested messages.

>             But global no-consoles doesn't really fit in here because
> each console might require a different policy but the marking is
> unconditional and largely unaware of existing consoles.

Why unconditional? I'm saying that users of KERN_NO_CONSOLES marking (in other
words, "whether the message is good enough for console or not") should be
configurable via e.g. sysctl. If administrators want to use per-console loglevel
setting, they can tell the kernel not to mark KERN_NO_CONSOLES via e.g. sysctl.