Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752824AbeAQLJn (ORCPT + 1 other); Wed, 17 Jan 2018 06:09:43 -0500 Received: from mail-pl0-f53.google.com ([209.85.160.53]:46452 "EHLO mail-pl0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752275AbeAQLJk (ORCPT ); Wed, 17 Jan 2018 06:09:40 -0500 X-Google-Smtp-Source: ACJfBoufsNo+u+U8FOD2s8rF8w3B1QdKaJoGr7SAcFXY4N1cIjS7Q5OaBWMUyaZ1AWfimo8puQfKxpNmZpmMkrgAzBU= MIME-Version: 1.0 In-Reply-To: References: <001a11405130ff1e9705629eb53c@google.com> <20180117093225.GB20303@amd> From: Dmitry Vyukov Date: Wed, 17 Jan 2018 12:09:18 +0100 Message-ID: Subject: Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run To: Daniel Borkmann Cc: Pavel Machek , syzbot , Alexei Starovoitov , LKML , netdev , syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann wrote: > Don't know if there's such a possibility, but it would be nice if we could > target fuzzing for specific subsystems in related subtrees directly (e.g. > for bpf in bpf and bpf-next trees as one example). Dmitry? Hi Daniel, It's doable. Let's start with one bpf tree. Will it be bpf or bpf-next? Which one contains more ongoing work? What's the exact git repo address/branch, so that I don't second guess? Also what syscalls it makes sense to enable there to target it at bpf specifically? As far as I understand effects of bpf are far beyond the bpf call and proper testing requires some sockets and other stuff. For sockets, will it be enough to enable ip/ipv6? Because if we enable all of sctp/dccp/tipc/pptp/etc, it will sure will be finding lots of bugs there as well. Does bpf affect incoming network packets? Also are there any sysctl's, command line arguments, etc that need to be tuned. I know there are net.core.bpf_jit_enable/harden, but I don't know what's the most relevant combination. Ideally, we test all of them, but let start with one of them because it requires separate instances (since the setting is global and test programs can't just flip it randomly). Also do you want testing from root or not from root? We generally don't test under root, because syzkaller comes up with legal ways to shut everything down even if we try to contain it (e.g. kill init somehow or shut down network using netlink). But if we limit syscall surface, then root may work and allow testing staging bpf features. > Anyway, thanks for all the great work on improving syzkaller! Thanks! So nice to hear, especially in the context of this thread.