linux-kernel - Re: printk meeting at LPC

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: <20190917081144.g254hccous7haavu@pathway.suse.cz>
Date:   Tue, 17 Sep 2019 10:11:44 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     John Ogness <john.ogness@...utronix.de>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Andrea Parri <parri.andrea@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
        Brendan Higgins <brendanhiggins@...gle.com>,
        Paul Turner <pjt@...gle.com>,
        Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Theodore Ts'o <tytso@....edu>,
        Prarit Bhargava <prarit@...hat.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: printk meeting at LPC

On Mon 2019-09-16 16:28:54, John Ogness wrote:
> On 2019-09-16, Steven Rostedt <rostedt@...dmis.org> wrote:
> >>>> 9. Support for printk dictionaries will be discontinued. I will
> >>>> look into who is using this and why. If printk dictionaries are
> >>>> important for you, speak up now!
> >>> 
> >>> I think that dev_printk() is using "const char *dict, size_t
> >>> dictlen," part via create_syslog_header(). Some userspace programs
> >>> might depend on availability of such information.
> >> 
> >> Yeah, but it seems to be the only dictionary writer. There were
> >> doubts (during the meeting) whether anyone was actually using the
> >> information.
> >> 
> >> Hmm, it seems that journalctl is able to filer device specific
> >> information, for example, I get:
> >> 
> >> $> journalctl _KERNEL_DEVICE=+usb:2-1  
> >> -- Logs begin at Tue 2019-08-13 09:00:03 CEST, end at Mon 2019-09-16 12:32:58 CEST. --
> >> Aug 13 09:00:04 linux-qszd kernel: usb 2-1: new high-speed USB device number 2 using ehci-pci
> >> 
> >> One question is if anyone is using this filtering. Simple grep is
> >> enough. Another question is whether it really needs to get passed
> >> this way.
> >> 
> >
> > If worse comes to worse, perhaps we let the console decide what to do
> > with it. Where all consoles but the "kmsg" one ignores it?

/dev/kmsg is one interface passing dictionary. The other is
netconsole. It is the only console with CON_EXTENDED flag set.

> > Then journalctl should work as normal.
> >
> > Or will this break one of our other changes?

It just complicates the code because we need to store and read
the information separately.


> The consoles will just iterate the ringbuffer. So if any console needs
> dictionary information, that information needs to be stored in the
> ringbuffer as well.
> 
> The dictionary text and message text could be stored as concatenated
> strings. The descriptor would point separately to the beginning of
> dictionary and message. So the data-buffer would still be a clean
> collection of text. But AFAIK Linus didn't want to see that "extra" text
> at all.

I would double check with Linus that he would consider this as
breaking userspace.

IMHO, it is perfectly fine to add this support later in separate patch(set) if
really necessary. I can't imagine that anyone would depend on this
feature when bisecting kernel. We could discuss and handle this later.
At least after the merge window.

> If we want to keep dictionary text out of the data-buffer, we could have
> a 2nd data-buffer dedicated for dictionary text. I expect it would not
> really complicate things. Especially if the dictionary part was "best
> effort" (i.e. if the dictionary text does not fit in the free part of
> its data-buffer, it is dropped).

Interesting idea. I like it if it does not complicate the code too much.

Best Regards,
Petr