On Tue, Jul 1, 2014 at 1:05 AM, Daniel Borkmann [off-list ref] wrote:

On 06/28/2014 02:06 AM, Alexei Starovoitov wrote:

quoted

Safety of eBPF programs is statically determined by the verifier, which
detects:
- loops
- out of range jumps
- unreachable instructions
- invalid instructions
- uninitialized register access
- uninitialized stack access
- misaligned stack access
- out of range stack access
- invalid calling convention

...

quoted

More details in Documentation/networking/filter.txt

Signed-off-by: Alexei Starovoitov <ast-uqk4Ao+rVK5Wk0Htik3J/w@public.gmane.org>
---

...

quoted

  kernel/bpf/verifier.c               | 1431
+++++++++++++++++++++++++++++++++++

Looking at classic BPF verifier which checks safety of BPF
user space programs, it's roughly 200 loc. :-/

I'm not sure what's your point comparing apples to oranges.
For the record 1431 lines include ~200 lines worth of comments
and 200 lines of verbose prints. Without them rejected eBPF
program is black box. Users need a way to understand why
verifier rejected it.

quoted

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
new file mode 100644

...

quoted

+#define _(OP) ({ int ret = OP; if (ret < 0) return ret; })

...

quoted

+       _(get_map_info(env, map_id, &map));

...

quoted

+       _(size = bpf_size_to_bytes(bpf_size));

Nit: such macros should be removed, please.

It may surely look unconventional, but alternative is to replace
every usage of _ macro with:
err = …
if (err)
  return err;

and since this macro is used 38 times, it will add ~120 unnecessary
lines that will only make code much harder to follow.
I tried not using macro and results were not pleasing.