[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACT4Y+Z6bbnHP6NhOb_v5cEXBiQm5AQqmqmSDbgty6x=ghDK_w@mail.gmail.com>
Date: Thu, 18 Jan 2018 14:10:38 +0100
From: Dmitry Vyukov <dvyukov@...gle.com>
To: Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: syzbot <syzbot+48340bb518e88849e2e3@...kaller.appspotmail.com>,
Alexei Starovoitov <ast@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
netdev <netdev@...r.kernel.org>
Subject: Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run
On Wed, Jan 17, 2018 at 12:09 PM, Dmitry Vyukov <dvyukov@...gle.com> wrote:
> On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann <daniel@...earbox.net> 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.
So, Daniel, Alexei,
I understand that I asked lots of questions, but they are relatively
simple. I need that info to setup proper testing.
Powered by blists - more mailing lists