From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 59920C433DF for ; Fri, 15 May 2020 14:58:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 38A35207C4 for ; Fri, 15 May 2020 14:58:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="OQBEEuAW" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726313AbgEOO6w (ORCPT ); Fri, 15 May 2020 10:58:52 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:52369 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726255AbgEOO6v (ORCPT ); Fri, 15 May 2020 10:58:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1589554730; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=p+H7G6hzBr30+LKXx0+swEd83bo5aBgRovoEz/J8OyM=; b=OQBEEuAWukkXVYEm3Bl2vM8hbkGs2xSFxGvIjtOsg37wDzLQIPjL8H0worzQjPUNWrYmcb PcFxIeLFPkwTPYOZ/kGNaxqEtLpIkv0TWNrwOKYWMSwNjvJjtNui3emniJPKdPvhS97iDm 2da3VP3/8h5lAzMPCmBdOAkwt/sn/Pg= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-512-yHP43npAOQ2idbyzQ3HAaQ-1; Fri, 15 May 2020 10:58:46 -0400 X-MC-Unique: yHP43npAOQ2idbyzQ3HAaQ-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 1E14A80183C; Fri, 15 May 2020 14:58:44 +0000 (UTC) Received: from krava (unknown [10.40.194.127]) by smtp.corp.redhat.com (Postfix) with SMTP id AD1CC1001B07; Fri, 15 May 2020 14:58:40 +0000 (UTC) Date: Fri, 15 May 2020 16:58:39 +0200 From: Jiri Olsa To: Andrii Nakryiko Cc: Jiri Olsa , Alexei Starovoitov , Daniel Borkmann , Networking , bpf , Yonghong Song , Martin KaFai Lau , David Miller , John Fastabend , Jesper Dangaard Brouer , Wenbo Zhang , KP Singh , Andrii Nakryiko , Brendan Gregg , Florent Revest , Al Viro Subject: Re: [PATCH 3/9] bpf: Add bpfwl tool to construct bpf whitelists Message-ID: <20200515145839.GD3565839@krava> References: <20200506132946.2164578-1-jolsa@kernel.org> <20200506132946.2164578-4-jolsa@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 Sender: bpf-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: bpf@vger.kernel.org On Thu, May 14, 2020 at 03:20:19PM -0700, Andrii Nakryiko wrote: > On Wed, May 6, 2020 at 6:30 AM Jiri Olsa 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 > > --- > > 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; > > + > > [...] >