linux-kernel - Re: kernel CI: printk loglevels in kernel boot logs?

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:   Wed, 22 Nov 2017 20:52:45 +0800
From:   Fengguang Wu <fengguang.wu@...el.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Petr Mladek <pmladek@...e.com>,
        Kevin Hilman <khilman@...libre.com>,
        Mark Brown <broonie@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: kernel CI: printk loglevels in kernel boot logs?

On Wed, Nov 22, 2017 at 09:38:21PM +0900, Sergey Senozhatsky wrote:
>On (11/22/17 12:34), Petr Mladek wrote:
>[..]
>> > > > This is espeically useful when ingesting kernel logs into advanced
>> > > > search/analytics frameworks (I'm playing with and ELK stack: Elastic
>> > > > Search, Logstash, Kibana).
>[..]
>> To make it clear. I understand that "show_loglevel" command line argument
>> would be useful for you. But I am afraid that it is not worth changing
>> the format. There would need to be wide interest into the change.
>> Also there would need to be evidence that the existing solutions
>> (dmesg --raw, console_loglevel) are not enough in many real life
>> scenarios.
>
>well, I think that that "consoles_format=syslog" command line parameter
>will be enabled only by those who actually want to have it - Fengguang's
>build robot and kernelCI (+ may be more setups).  so I'd probably assume
>there are low risks here. may be I'm wrong.

Yes, since it needs explicit enabling, local parsers should stay
working. Unless we send dmesg to other developers, but then they
might also receive $(dmesg --raw) outputs and need to handle <%u>
prefixes, too.

>I think it makes sense to have syslog's format "<%u>[timestamp] text\n"
>on serial consoles (time stamp when PRINTK_TIME set; <%u> when
>consoles_format=syslog set).

Thanks. Since the 0day scripts can already parse that format (code
is listed below), we should quickly benefit from that feature when
it's mainlined.

https://github.com/fengguang/lkp-tests/blob/master/lib/dmesg.rb

    oops = `#{grep} -a -E -e '^<[0123]>' -e '^kern  :(err   |crit  |alert |emerg ): ' #{kmsg_file} |
      sed -r 's/\\x1b\\[([0-9;]+m|[mK])//g' |
      grep -a -v -E -f #{LKP_SRC}/etc/oops-pattern |
      grep -a -v -F -f #{LKP_SRC}/etc/kmsg-blacklist`

Thanks,
Fengguang