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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Thu, 12 Mar 2020 18:29:35 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc:     Dmitry Vyukov <dvyukov@...gle.com>, Jiri Slaby <jslaby@...e.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH v2] Add kernel config option for fuzz testing.

On Fri, 13 Mar 2020 06:59:22 +0900
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp> wrote:

> On 2020/03/13 4:23, Dmitry Vyukov wrote:
> >> Or teach the fuzz tool not to do specific bad things.  
> > 
> > We do some of this.
> > But generally it's impossible for anything that involves memory
> > indirections, or depends on the exact type of fd (e.g. all ioctl's),
> > etc. Boils down to halting problem and ability to predict exact
> > behavior of arbitrary programs.  
> 
> I would like to enable changes like below only if CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y .
> 
> Since TASK_RUNNING threads are not always running on CPUs (in syzbot, the kernel is
> tested on a VM with only 2 CPUs, which means that many threads are simply waiting for
> CPU time to be assigned), dumping locks held by all threads gives us more clue when
> e.g. khungtask fired. But since lockdep_print_held_locks() is racy, I assume that
> this change won't be accepted unless CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y .
> 
> Also, for another example, limit number of memory pages /dev/ion driver can consume only if
> CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y ( https://github.com/google/syzkaller/issues/1267 ),
> for limiting number of memory pages is a user-visible change while we need to avoid false
> alarms caused by consuming all memory pages.
> 
> In other words, while majority of things CONFIG_KERNEL_BUILT_FOR_FUZZ_TESTING=y would
> do "disable this", there would be a few "enable this" and "change this".

I still fear that people will just disable large sections. I've seen this
before. Developers take the easy way out, and when someone adds a new
feature that may be dangerous, they will just say "oh turn off fuzzing" and
be done with it.

As Linus likes to say, when you need to make changes to the kernel to test
it, you are no longer testing production kernels.

> 
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 32406ef0d6a2..1bc7878768fc 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -695,6 +695,7 @@ static void print_lock(struct held_lock *hlock)
>  static void lockdep_print_held_locks(struct task_struct *p)
>  {
>  	int i, depth = READ_ONCE(p->lockdep_depth);
> +	bool unreliable;
>  
>  	if (!depth)
>  		printk("no locks held by %s/%d.\n", p->comm, task_pid_nr(p));
> @@ -705,10 +706,12 @@ static void lockdep_print_held_locks(struct task_struct *p)
>  	 * It's not reliable to print a task's held locks if it's not sleeping
>  	 * and it's not the current task.
>  	 */
> -	if (p->state == TASK_RUNNING && p != current)
> -		return;
> +	unreliable = p->state == TASK_RUNNING && p != current;
>  	for (i = 0; i < depth; i++) {
> -		printk(" #%d: ", i);
> +		if (unreliable)
> +			printk(" #%d?: ", i);
> +		else
> +			printk(" #%d: ", i);

Have you tried submitting this? Has Peter nacked it?

-- Steve

>  		print_lock(p->held_locks + i);
>  	}
>  }