linux-kernel - Re: printk feature for syzbot?

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: <20180426100603.czif6sat75fjsazp@pathway.suse.cz>
Date:   Thu, 26 Apr 2018 12:06:03 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        syzkaller <syzkaller@...glegroups.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Fengguang Wu <fengguang.wu@...el.com>,
        linux-kernel@...r.kernel.org
Subject: Re: printk feature for syzbot?

On Tue 2018-04-24 10:33:36, Sergey Senozhatsky wrote:
> Yes, Tetsuo, we use a bunch of "printk prefix" extensions at Samsung.
> For instance, we prefix printk messages with the CPU number: messages
> sometimes mix up, we also see partial pr_cont flushes, and so on.
> Grep-ping serial logs by CPU number is quite powerful.
> 
> Upstreaming those printk prefixes can be a bit challenging, but may
> be it's not all so bad. I personally think that syzbot, and build-test
> bots in general [like 0day], are helpful indeed, and I don't see why life
> should be any more complex for syzbot/0day guys. If printk prefixes can
> help - then we probably should consider such an extension.
> 
> The main argument from the upstream is that tweaking struct printk_log
> breaks user space (tools like crash, and so on). But I guess we can do
> something about it. E.g. put a PRINTK_CONTEXT_TRACKING_PREFIX kconfig
> option somewhere in "Kernel hacking"->"printk and dmesg options" and
> make available only for DEBUG kernels, or something similar.

> Petr, Steven, Fengguang, what do you think? Do you have any objections?
> Ideas?

I wonder if we could create some mechanism that would help to extend
struct printk_log easier in the future.

I know only about crash tool implementation. It uses information provided
by log_buf_vmcoreinfo_setup(). The size of the structure is already
public. Therefore crash should be able to find all existing information
even if we increase the size of the structure.

log_buf_vmcoreinfo_setup() even allows to inform about newly added
structure items. We could probably extend it to inform also about
the offset of the new optional elements.

I am not sure about other tools. But I think that it should be
doable.

Best Regards,
Petr