[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200515145839.GD3565839@krava>
Date: Fri, 15 May 2020 16:58:39 +0200
From: Jiri Olsa <jolsa@...hat.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Yonghong Song <yhs@...com>, Martin KaFai Lau <kafai@...com>,
David Miller <davem@...hat.com>,
John Fastabend <john.fastabend@...il.com>,
Jesper Dangaard Brouer <hawk@...nel.org>,
Wenbo Zhang <ethercflow@...il.com>,
KP Singh <kpsingh@...omium.org>,
Andrii Nakryiko <andriin@...com>,
Brendan Gregg <bgregg@...flix.com>,
Florent Revest <revest@...omium.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: [PATCH 3/9] bpf: Add bpfwl tool to construct bpf whitelists
On Thu, May 14, 2020 at 03:20:19PM -0700, Andrii Nakryiko wrote:
> On Wed, May 6, 2020 at 6:30 AM Jiri Olsa <jolsa@...nel.org> wrote:
> >
> > This tool takes vmlinux object and whitelist directory on input
> > and produces C source object with BPF whitelist data.
> >
> > The vmlinux object needs to have a BTF information compiled in.
> >
> > The whitelist directory is expected to contain files with helper
> > names, where each file contains list of functions/probes that
> > helper is allowed to be called from - whitelist.
> >
> > The bpfwl tool has following output:
> >
> > $ bpfwl vmlinux dir
> > unsigned long d_path[] __attribute__((section(".BTF_whitelist_d_path"))) = \
> > { 24507, 24511, 24537, 24539, 24545, 24588, 24602, 24920 };
>
> why long instead of int? btf_id is 4-byte one.
ok, int it is
>
> >
> > Each array are sorted BTF ids of the functions provided in the
> > helper file.
> >
> > Each array will be compiled into kernel and used during the helper
> > check in verifier.
> >
> > Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> > ---
> > tools/bpf/bpfwl/Build | 11 ++
> > tools/bpf/bpfwl/Makefile | 60 +++++++++
> > tools/bpf/bpfwl/bpfwl.c | 285 +++++++++++++++++++++++++++++++++++++++
> > 3 files changed, 356 insertions(+)
> > create mode 100644 tools/bpf/bpfwl/Build
> > create mode 100644 tools/bpf/bpfwl/Makefile
> > create mode 100644 tools/bpf/bpfwl/bpfwl.c
>
> Sorry, I didn't want to nitpick on naming, honestly, but I think this
> is actually harmful in the long run. bpfwl is incomprehensible name,
> anyone reading link script would be like "what the hell is bpfwl?" Why
> not bpf_build_whitelist or something with "whitelist" spelled out in
> full?
hum, will pick some more generic name
>
> >
> > diff --git a/tools/bpf/bpfwl/Build b/tools/bpf/bpfwl/Build
> > new file mode 100644
> > index 000000000000..667e30d6ce79
> > --- /dev/null
> > +++ b/tools/bpf/bpfwl/Build
> > @@ -0,0 +1,11 @@
> > +bpfwl-y += bpfwl.o
> > +bpfwl-y += rbtree.o
> > +bpfwl-y += zalloc.o
> > +
>
> [...]
>
> > +
> > +struct func {
> > + char *name;
> > + unsigned long id;
>
> as mentioned above, btf_id is 4 byte
ok, changing to int
>
> > + struct rb_node rb_node;
> > + struct list_head list[];
> > +};
> > +
>
> [...]
>
> > + btf = btf__parse_elf(vmlinux, NULL);
> > + err = libbpf_get_error(btf);
> > + if (err) {
> > + fprintf(stderr, "FAILED: load BTF from %s: %s",
> > + vmlinux, strerror(err));
> > + return -1;
> > + }
> > +
> > + nr = btf__get_nr_types(btf);
> > +
> > + /* Iterate all the BTF types and resolve all the function IDs. */
> > + for (id = 0; id < nr; id++) {
>
> It has to be `for (id = 1; id <= nr; id++)`. 0 is VOID type and not
> included into nr_types. I know it's confusing, but.. life :)
right, will change
thanks,
jirka
>
> > + const struct btf_type *type;
> > + struct func *func;
> > + const char *str;
> > +
> > + type = btf__type_by_id(btf, id);
> > + if (!type)
> > + continue;
> > +
>
> [...]
>
Powered by blists - more mailing lists