Kernel config for fuzz testing.

From: Tetsuo Handa
Date: Tue Oct 08 2019 - 05:58:24 EST


On 2019/08/23 17:17, Tetsuo Handa wrote:
> On 2019/08/23 8:59, Dmitry Vyukov wrote:
>>> Can't we introduce a kernel config which selectively blocks specific actions?
>>> If we don't need to worry about bypassing blacklist checks, we will be able to
>>> enable syz_execute_func() again.
>>
>>
>> We can consider this, but we need some set of good use cases first.
>> For /dev/{mem,kmem} we disable them with config, right?
>
> /dev/{mem,kmem} can be disabled by kernel config options. But
>
>> That looks
>> like the right thing to do because we don't want fuzzer to do anything
>> with these files anyway.
>
> I don't think so. To examine as corner as possible (e.g. lock dependency),
> I consider that even doing
>
> ----------
> +#ifdef CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING
> +static char dummybuf[PAGE_SIZE];
> +#endif
> ----------
>
> ----------
> ptr = xlate_dev_mem_ptr(p);
> if (!ptr) {
> if (written)
> break;
> return -EFAULT;
> }
> +#ifndef CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING
> copied = copy_from_user(ptr, buf, sz);
> +#else
> + copied = copy_from_user(dummybuf, buf, min(sizeof(dummybuf), sz));
> +#endif
> unxlate_dev_mem_ptr(p, ptr);
> ----------
>
> makes sense, for copy_from_user() might find new lock dependency
> which would otherwise be unnoticed.
>
>> So this won't be a good use case for
>> CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING.
>> Fuzzer can also reliably filter out based on syscall numbers of
>> top-level argument values. The potential problem is with (1)
>> pointers/indirect memory and (2) where blacklisting some top-level
>> argument values would backlist too much (e.g. prohibiting 3rd ioctl
>> argument 0 entirely).
>
> I consider that functions that freezes processes/filesystems,
> reboots/shutdowns a system, changes console loglevels can be blocked
> as well. Trying to examine up to last-second conditional branches will
> catch more bugs (e.g. bugs in error recovery paths).
>

A USB fuzz test is triggering SysRq-t until RCU stall happens. ;-)
Can we introduce a kernel config (for linux.git) which selectively
blocks specific actions?

https://syzkaller.appspot.com/text?tag=CrashLog&x=12eb1e67600000

[ 563.439044][ C1] ksoftirqd/1 R running task 28264 16 2 0x80004008
[ 563.447037][ C1] Call Trace:
[ 563.450321][ C1] sched_show_task.cold+0x2e0/0x359
[ 563.455502][ C1] show_state_filter+0x164/0x209
[ 563.460421][ C1] ? fn_caps_on+0x90/0x90
[ 563.464730][ C1] k_spec+0xdc/0x120
[ 563.468605][ C1] kbd_event+0x927/0x3790
[ 563.472914][ C1] ? k_pad+0x720/0x720
[ 563.476964][ C1] ? mark_held_locks+0xe0/0xe0
[ 563.481791][ C1] ? sysrq_filter+0xdf/0xeb0
[ 563.486359][ C1] ? k_pad+0x720/0x720
[ 563.490419][ C1] input_to_handler+0x3b6/0x4c0
[ 563.495247][ C1] input_pass_values.part.0+0x2e3/0x720
[ 563.500770][ C1] input_repeat_key+0x1ee/0x2c0
[ 563.505622][ C1] ? input_dev_suspend+0x80/0x80
[ 563.510535][ C1] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 563.515805][ C1] call_timer_fn+0x179/0x650
[ 563.520385][ C1] ? input_dev_suspend+0x80/0x80
[ 563.525389][ C1] ? msleep_interruptible+0x130/0x130
[ 563.531528][ C1] ? rcu_read_lock_sched_held+0x9c/0xd0
[ 563.537058][ C1] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 563.542334][ C1] ? _raw_spin_unlock_irq+0x24/0x30
[ 563.547519][ C1] ? input_dev_suspend+0x80/0x80
[ 563.552443][ C1] run_timer_softirq+0x5e3/0x1490
[ 563.557454][ C1] ? add_timer+0x7a0/0x7a0
[ 563.561853][ C1] ? rcu_read_lock_sched_held+0x9c/0xd0
[ 563.567377][ C1] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 563.572644][ C1] __do_softirq+0x221/0x912
[ 563.577147][ C1] ? takeover_tasklets+0x720/0x720
[ 563.582246][ C1] run_ksoftirqd+0x1f/0x40
[ 563.586638][ C1] smpboot_thread_fn+0x3e8/0x850
[ 563.591640][ C1] ? smpboot_unregister_percpu_thread+0x190/0x190
[ 563.598031][ C1] ? __kthread_parkme+0x10a/0x1c0
[ 563.603031][ C1] ? smpboot_unregister_percpu_thread+0x190/0x190
[ 563.609440][ C1] kthread+0x318/0x420
[ 563.613746][ C1] ? kthread_create_on_node+0xf0/0xf0
[ 563.619092][ C1] ret_from_fork+0x24/0x30