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: <20200424114225.5a3bab7e@gandalf.local.home>
Date:   Fri, 24 Apr 2020 11:42:25 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        linux-kernel@...r.kernel.org, Dmitry Safonov <dima@...sta.com>,
        Michal Hocko <mhocko@...e.com>,
        Yafang Shao <laoar.shao@...il.com>
Subject: Re: [PATCH] printk: Add loglevel for "do not print to consoles".

On Sat, 25 Apr 2020 00:28:53 +0900
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> wrote:

> On 2020/04/24 23:31, Steven Rostedt wrote:
> > On Fri, 24 Apr 2020 23:00:01 +0900
> > Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> wrote:
> >   
> >> Since KERN_NO_CONSOLES is for -ENOMEM situations (GFP_KERNEL allocation which
> >> can sleep needs to invoke the OOM killer, or GFP_ATOMIC allocation which cannot
> >> sleep has failed), we can't create buffer on demand. For process context, it
> >> would be possible to create buffer upon fork() time. But for atomic context,
> >> it is so difficult to create buffer on demand. We could allocate shared buffer
> >> like logbuf but it means that we have to replicate what printk() is doing (too
> >> much code), for when atomic memory allocation happens resembles when printk()
> >> is called. Borrowing printk()'s logbuf is simpler.  
> > 
> > I would have a buffer allocated for this at start up.  
> 
> Allocating global buffer itself is simple (except that it might waste a lot of
> memory). Difficult part is how to use the buffer.

I agree with Michal that this really should be a user setting (something on
the command line or sysctl - allocation at the time of decision).

> 
> > 
> > What exactly would you be "replicating" in printk?  
> 
> Making it possible to store into global buffer from almost any context (not only
> process context but also softirq/hardirq/NMI context (well, is memory allocation
>  from NMI context not permitted? I don't know... but future KERN_NO_CONSOLES
> users might want to call from NMI context)), notify userspace program of data
> readiness, and manage the buffer.

printk() was not safe in NMI context up until very recently.

You can also use the tracing ring buffer for this, as it has been safe in
all these contexts for a very long time. And that ring buffer is something
that you can use outside of tracing (oprofile uses it).


> 
> KERN_NO_CONSOLES does not need to call call_console_drivers(). But basically
> things what printk() is doing.
> 
> >                                                    The point of printk is
> > to print to a console, not to be a generic ring buffer. This change is
> > breaking printk's most useful feature.  
> 
> For those who analyze log files (instead of console output), the point of
> printk() is to save kernel messages into log files (via userspace syslog
> daemon).
> 
> By the way, I think
> 
>   printk(KERN_NO_CONSOLES "hello\n")
> 
> is almost same with doing
> 
>   saved_loglevel = console_loglevel;
>   console_loglevel = CONSOLE_LOGLEVEL_SILENT;
>   printk("hello\n");
>   console_loglevel = saved_loglevel;
> 
> used by vkdb_printf().

And both shouldn't be done within the kernel. The "CONSOLE_LOGLEVEL_SILENT"
if for user decided policy, not the kernel making that policy for the user.

-- Steve