[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191219211803.GA59959@mit.edu>
Date: Thu, 19 Dec 2019 16:18:03 -0500
From: "Theodore Y. Ts'o" <tytso@....edu>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Andi Kleen <ak@...ux.intel.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
Petr Mladek <pmladek@...e.com>,
Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
Arnd Bergmann <arnd@...db.de>, Jiri Slaby <jslaby@...e.com>,
Steven Rostedt <rostedt@...dmis.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] kconfig: Add kernel config option for fuzz testing.
On Thu, Dec 19, 2019 at 06:43:37PM +0100, Dmitry Vyukov wrote:
> We can easily filter out syscall numbers and top level syscall
> argument values (executing random binary code aside, as we gave up on
> this for now). That's what we use to filter out reboot syscalls and
> FIFREEZE ioctl (fortunately the value does not collide with any other
> ioctl we have _for now_). This is done by scanning the test case and
> fixing it if necessary (all the necessary data is already there).
OK, but a number of the changs made in the patch in question (such as
filtering out FIFREEZE by adding a hacky check in the kernel) was done
because the claim was made that Syzkaller *wanted* to run random
binary code. If you given up for now, then maybe much or all of this
patch isn't needed?
If we do want to run random byte strings as instructions just to see
what the kernel will do, then some ugliness is going to be required.
The question is really, "where do we stash the ugliness", and who pays
the "ugliness tax", and are the benefits worth the costs?
- Ted
Powered by blists - more mailing lists