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
| ||
|
Date: Sat, 25 May 2019 09:14:15 +0900 From: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Andrew Morton <akpm@...ux-foundation.org>, Linux List Kernel Mailing <linux-kernel@...r.kernel.org>, Dmitry Vyukov <dvyukov@...gle.com>, Petr Mladek <pmladek@...e.com>, Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>, Joe Perches <joe@...ches.com> Subject: Re: [PATCH] printk: Monitor change of console loglevel. On 2019/05/25 2:17, Linus Torvalds wrote: > A config option or two that help syzbot doesn't sound like a bad idea to me. Thanks for suggestion. I think that #ifdef'ing static bool suppress_message_printing(int level) { return (level >= console_loglevel && !ignore_loglevel); } is simpler. If the cause of unexpected change of console loglevel turns out to be syz_execute_func(), we will want a config option which controls suppress_message_printing() for syzbot. That option would also be used for guarding printk("WARNING:" ...) users. Well, syzbot does not want to use ignore_loglevel kernel command line option because that option would generate too much output... https://lkml.kernel.org/r/CACT4Y+ay7nuT-7y2JARozV1s0VisuLdN6VT+w9OsEDs1PeBRoA@mail.gmail.com On 2019/05/25 2:55, Linus Torvalds wrote: > On Fri, May 24, 2019 at 10:41 AM Joe Perches <joe@...ches.com> wrote: > > > > That could also help eliminate unnecessary pr_<foo> output > > from object code. > > Indeed. The small-config people might like it (if they haven't already > given up..) Do you mean doing e.g. #define pr_debug(fmt, ...) no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__) depending on the minimal console loglevel kernel config option? Then, OK. But callers using e.g. printk(KERN_DEBUG ...) and printk(KERN_SOH "%u" ...) will remain unfiltered...
Powered by blists - more mailing lists