Re: [PATCH] kconfig: Add kernel config option for fuzz testing.

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Tue, Dec 17, 2019 at 09:36:43AM +0100, Dmitry Vyukov wrote:
> Yes, what Tetsuo says. Only syscall numbers and top-level arguments to
> syscalls are easy to filter out. When indirect memory is passed to
> kernel or (fd,ioctl) pairs are involved it boils down to solving the
> halting problem.

I disagree that it's equivalent to solving the halting problem.
Otherwise, we couldn't filter in the kernel.  Let's think about ways
we can solve this.  One is to simply do what valgrind does; this
handles even self-modifying code, since you're essentially running an
x86-to-x86 emulator, and then you find an attempted trap to the
kernel, you can transfer control to a program which vets the arguments
to the system call.

Another approach might be to do this filtering in an BPF hook
installed at syscall entry.  Technically this is being done in the
kernel, but the advantage of this approach is that the BPF program can
be distributed alongside Syzkaller, and it can be Syzkaller-specific.
That way when we need to add a new blacklist entry, it can be done
without needing to wait for a kernel patch.

And note that there may *always* be some ioctls which we will need to
suppress.  For example, an attempt to send a SANITIZE ERASE to a
storage device; or an attempt to freeze the root file system, etc.
And I'm not sure all of these are ones that we can prevent by using
the lockdown setting.  There may very well be some commands that a
legitamate system administrator might want to execute that will, when
executed in the wrong circumstances causes the system to crash.  But
so long as it doesn't violate the trusted boot semantics which are the
whole point of lockdown, we would need to allow them.

So I suspect that some kind of filtering which is Syzkaller specific
is going to be inevitably needed, if you want to throw random binary
code and see what causes problem, and you insist on allowing these
random binary bits to be run as root.  Trying to prevent root from
being able to kill or self-DOS a machine goes way beyond any of our
current security mechanisms, and is something which is only really
needed by Fuzzers.  Personally, I suspect some kind of BPF filtering
is probably your best bet, since it will a bit more architecturally
portable than using some kind of Valgrind-like approach.  (Although
Valgrind *does* most of the architectures that I suspect we're going
to care about.)

						- Ted