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]

Message-ID: <7e0d2bbf-71c2-395c-9a42-d3d6d3ee4fa4@i-love.sakura.ne.jp>
Date:   Fri, 13 Mar 2020 06:59:22 +0900
From:   Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
To:     Steven Rostedt <rostedt@...dmis.org>
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>
Subject: Re: [PATCH v2] Add kernel config option for fuzz testing.

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".

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);
 		print_lock(p->held_locks + i);
 	}
 }