Messages in this thread | | | Date | Tue, 1 Jul 2014 13:04:41 -0700 | Subject | Re: [PATCH RFC net-next 08/14] bpf: add eBPF verifier | From | Alexei Starovoitov <> |
| |
On Tue, Jul 1, 2014 at 1:05 AM, Daniel Borkmann <dborkman@redhat.com> wrote: > On 06/28/2014 02:06 AM, Alexei Starovoitov wrote: >> >> 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 > > ... > >> More details in Documentation/networking/filter.txt >> >> Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> >> --- > > ... >> >> 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.
> >> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c >> new file mode 100644 > > ... > >> +#define _(OP) ({ int ret = OP; if (ret < 0) return ret; }) > > ... >> >> + _(get_map_info(env, map_id, &map)); > > ... >> >> + _(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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |