linux-kernel - Re: [PATCH v2] Add kernel config option for fuzz testing.

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3ee9c586-002b-f504-9e3b-5afa8929209b@i-love.sakura.ne.jp>
Date:   Mon, 9 Mar 2020 20:22:47 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Jiri Slaby <jslaby@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Garrett <mjg59@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        "Theodore Y . Ts'o" <tytso@....edu>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Petr Mladek <pmladek@...e.com>,
        Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
        Arnd Bergmann <arnd@...db.de>,
        Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH v2] Add kernel config option for fuzz testing.

On 2020/03/09 1:13, Linus Torvalds wrote:
> On Sun, Mar 8, 2020 at 12:53 AM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
>>
>> No, anything that just evaluates the code should be fine, we want static
>> analyzers to be processing those code paths.  Just not to run them as
>> root on a live system.
> 
> So I can see the reason to run fuzz testing as root, but I have to
> admit to hating the "special config option for this" approach.
> 
> I'd *much* rather see some way to just lock down certain things
> individually. The patch in here just added the config option, which is
> the least interesting part.

I think that locking down individual thing using individual switch is an
endless game of maintaining list of switches. When someone adds a code
which should not be fuzzed, the author of that code or the maintainer of
fuzzers will add a new switch for that code, and the maintainer of fuzzers
forever has to follow new switches. I think that it is better to keep number
of switches minimal until we have to split into fine grained switches.

> 
> The things that that config option then would want to disable - those
> are the things that maybe we want to have a way for the system admin
> just generally say "disable this".
> 
> Nothing to do with fuzzing, imho.
> 
>             Linus
>