All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <ast@plumgrid.com>
To: Daniel Borkmann <dborkman@redhat.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Ingo Molnar <mingo@kernel.org>,
	Linus Torvalds <torvalds@linuxfoundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Steven Rostedt <rostedt@goodmis.org>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>,
	Chema Gonzalez <chema@google.com>,
	Eric Dumazet <edumazet@google.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Pablo Neira Ayuso <pablo@netfilter.org>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andrew Morton <akpm@linuxfoundation.org>,
	Kees Cook <keescook@chromium.org>,
	Linux API <linux-api@vger.kernel.org>,
	Network Development <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v11 net-next 12/12] bpf: mini eBPF library, test stubs and verifier testsuite
Date: Wed, 10 Sep 2014 11:08:40 -0700	[thread overview]
Message-ID: <CAMEtUuzEQu30WiYprRcDBogJxxrDeNhvn=kF+z8cVvhR-vjTQg@mail.gmail.com> (raw)
In-Reply-To: <54103776.3080706@redhat.com>

On Wed, Sep 10, 2014 at 4:35 AM, Daniel Borkmann <dborkman@redhat.com> wrote:
>
> Since we already have an extensive BPF test suite, that is, lib/test_bpf.c,
> which currently also does sanity checks for the classic BPF verifier, is
> there a reason these verifier test cases cannot be extended/integrated there
> as well but have to go to kernel/bpf/test_stub.c resp.
> samples/bpf/test_verifier.c ?
> I don't like that we put testing code into kernel/bpf/ whereas we already
> have a BPF test infrastructure in the kernel elsewhere.

yes. there is a reason. Verifier needs to be tested from user space,
since it works on fds. Process local map_fd are part of the eBPF
programs. Therefore one is testing things from kernel and
another from userspace. We definitely need both.
Currently there is no use case to call verifier from inside
the kernel. I'm not sure there will be one. Verifier's main
purpose is to check user supplied programs and provide
humans an understandable error messages of what
is 'unsafe' in particular program.
Eventually we will integrate this verifier messages with
program compilation. Like, the user would write a program
in C then invoke a wrapper of compiler and verifier, which
will point to lines in C code which are doing something
wrong like loops or out of bounds access. Currently verifier
complains about particular 'unsafe' instruction, but
humans have hard time correlating asm to C.

WARNING: multiple messages have this Message-ID (diff)
From: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
To: Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Linus Torvalds
	<torvalds-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Steven Rostedt <rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org>,
	Hannes Frederic Sowa
	<hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>,
	Chema Gonzalez <chema-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Peter Zijlstra
	<a.p.zijlstra-/NLkJaSkS4VmR6Xm/wNWPw@public.gmane.org>,
	Pablo Neira Ayuso <pablo-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>,
	"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
	Andrew Morton
	<akpm-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Network Development
	<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v11 net-next 12/12] bpf: mini eBPF library, test stubs and verifier testsuite
Date: Wed, 10 Sep 2014 11:08:40 -0700	[thread overview]
Message-ID: <CAMEtUuzEQu30WiYprRcDBogJxxrDeNhvn=kF+z8cVvhR-vjTQg@mail.gmail.com> (raw)
In-Reply-To: <54103776.3080706-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

On Wed, Sep 10, 2014 at 4:35 AM, Daniel Borkmann <dborkman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>
> Since we already have an extensive BPF test suite, that is, lib/test_bpf.c,
> which currently also does sanity checks for the classic BPF verifier, is
> there a reason these verifier test cases cannot be extended/integrated there
> as well but have to go to kernel/bpf/test_stub.c resp.
> samples/bpf/test_verifier.c ?
> I don't like that we put testing code into kernel/bpf/ whereas we already
> have a BPF test infrastructure in the kernel elsewhere.

yes. there is a reason. Verifier needs to be tested from user space,
since it works on fds. Process local map_fd are part of the eBPF
programs. Therefore one is testing things from kernel and
another from userspace. We definitely need both.
Currently there is no use case to call verifier from inside
the kernel. I'm not sure there will be one. Verifier's main
purpose is to check user supplied programs and provide
humans an understandable error messages of what
is 'unsafe' in particular program.
Eventually we will integrate this verifier messages with
program compilation. Like, the user would write a program
in C then invoke a wrapper of compiler and verifier, which
will point to lines in C code which are doing something
wrong like loops or out of bounds access. Currently verifier
complains about particular 'unsafe' instruction, but
humans have hard time correlating asm to C.

  reply	other threads:[~2014-09-10 18:08 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-10  5:09 [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite Alexei Starovoitov
2014-09-10  5:09 ` Alexei Starovoitov
2014-09-10  5:09 ` [PATCH v11 net-next 01/12] bpf: introduce BPF syscall and maps Alexei Starovoitov
2014-09-10  5:09 ` [PATCH v11 net-next 02/12] bpf: enable bpf syscall on x64 and i386 Alexei Starovoitov
2014-09-10  5:09 ` [PATCH v11 net-next 03/12] bpf: add lookup/update/delete/iterate methods to BPF maps Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 04/12] bpf: expand BPF syscall with program load/unload Alexei Starovoitov
2014-09-10  8:04   ` Daniel Borkmann
2014-09-10  8:04     ` Daniel Borkmann
2014-09-10 17:19     ` Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 05/12] bpf: handle pseudo BPF_CALL insn Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 06/12] bpf: verifier (add docs) Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 07/12] bpf: verifier (add ability to receive verification log) Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 08/12] bpf: handle pseudo BPF_LD_IMM64 insn Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 09/12] bpf: verifier (add branch/goto checks) Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 10/12] bpf: verifier (add verifier core) Alexei Starovoitov
2014-09-10  5:10   ` Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 11/12] net: filter: move eBPF instruction macros Alexei Starovoitov
2014-09-10 11:24   ` Daniel Borkmann
2014-09-10 11:24     ` Daniel Borkmann
2014-09-10 18:16     ` Alexei Starovoitov
2014-09-10 18:16       ` Alexei Starovoitov
2014-09-11  6:29       ` Daniel Borkmann
2014-09-11  6:45         ` Alexei Starovoitov
2014-09-10  5:10 ` [PATCH v11 net-next 12/12] bpf: mini eBPF library, test stubs and verifier testsuite Alexei Starovoitov
2014-09-10 11:35   ` Daniel Borkmann
2014-09-10 11:35     ` Daniel Borkmann
2014-09-10 18:08     ` Alexei Starovoitov [this message]
2014-09-10 18:08       ` Alexei Starovoitov
2014-09-17  7:16       ` Daniel Borkmann
2014-09-17  7:16         ` Daniel Borkmann
2014-09-17 16:17         ` Alexei Starovoitov
2014-09-17 21:59           ` Daniel Borkmann
2014-09-17 21:59             ` Daniel Borkmann
2014-09-17 22:16             ` Alexei Starovoitov
2014-09-10  8:19 ` [PATCH v11 net-next 00/12] eBPF syscall, verifier, testsuite Daniel Borkmann
2014-09-10  8:19   ` Daniel Borkmann
2014-09-10 17:28   ` Alexei Starovoitov
2014-09-10  9:03 ` Daniel Borkmann
2014-09-10 17:32   ` Alexei Starovoitov
2014-09-10 17:32     ` Alexei Starovoitov
2014-09-11 19:47     ` Daniel Borkmann
2014-09-11 19:47       ` Daniel Borkmann
2014-09-11 20:33       ` Alexei Starovoitov
2014-09-11 20:33         ` Alexei Starovoitov
2014-09-11 21:54         ` Andy Lutomirski
2014-09-11 21:54           ` Andy Lutomirski
2014-09-11 22:29           ` Alexei Starovoitov
2014-09-11 22:29             ` Alexei Starovoitov
2014-09-12  1:17             ` Andy Lutomirski
2014-09-12  1:29               ` Alexei Starovoitov
2014-09-12 22:40               ` Alexei Starovoitov
2014-09-10  9:21 ` Daniel Borkmann
2014-09-10 17:48   ` Alexei Starovoitov
2014-09-10 18:22 ` Andy Lutomirski
2014-09-10 20:21   ` Alexei Starovoitov
2014-09-10 20:21     ` Alexei Starovoitov
2014-09-11 19:54     ` Daniel Borkmann
2014-09-11 20:35       ` Alexei Starovoitov
2014-09-11 20:35         ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMEtUuzEQu30WiYprRcDBogJxxrDeNhvn=kF+z8cVvhR-vjTQg@mail.gmail.com' \
    --to=ast@plumgrid.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linuxfoundation.org \
    --cc=chema@google.com \
    --cc=davem@davemloft.net \
    --cc=dborkman@redhat.com \
    --cc=edumazet@google.com \
    --cc=hannes@stressinduktion.org \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=rostedt@goodmis.org \
    --cc=torvalds@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.