netdev - Re: [RFC bpf-next v3 6/9] tools: bpftool: add probes for eBPF helper functions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5522a6bf-0cec-e9dd-a45e-b3a56bd019e6@netronome.com>
Date:   Thu, 3 Jan 2019 17:26:41 +0000
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Stanislav Fomichev <sdf@...gle.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, netdev@...r.kernel.org,
        oss-drivers@...ronome.com,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>
Subject: Re: [RFC bpf-next v3 6/9] tools: bpftool: add probes for eBPF helper
 functions

2019-01-03 09:15 UTC-0800 ~ Stanislav Fomichev <sdf@...gle.com>
> On Thu, Jan 3, 2019 at 6:03 AM Quentin Monnet
> <quentin.monnet@...ronome.com> wrote:
>>
>> Similarly to what was done for program types and map types, add a set of
>> probes to test the availability of the different eBPF helper functions
>> on the current system.
>>
>> For each known program type, all known helpers are tested, in order to
>> establish a compatibility matrix. Output is provided as a set of lists
>> of available helpers, one per program type.
>>
>> Sample output:
>>
>>     # bpftool feature probe kernel
>>     ...
>>     Scanning eBPF helper functions...
>>     eBPF helpers supported for program type socket_filter:
>>             - bpf_map_lookup_elem
>>             - bpf_map_update_elem
>>             - bpf_map_delete_elem
>>     ...
>>     eBPF helpers supported for program type kprobe:
>>             - bpf_map_lookup_elem
>>             - bpf_map_update_elem
>>             - bpf_map_delete_elem
>>     ...
>>
>>     # bpftool --json --pretty feature probe kernel
>>     {
>>         ...
>>         "helpers": {
>>             "socket_filter_available_helpers": ["bpf_map_lookup_elem", \
>>                     "bpf_map_update_elem","bpf_map_delete_elem", ...
>>             ],
>>             "kprobe_available_helpers": ["bpf_map_lookup_elem", \
>>                     "bpf_map_update_elem","bpf_map_delete_elem", ...
>>             ],
>>             ...
>>         }
>>     }
>>
>> v3:
>> - Do not pass kernel version from bpftool to libbpf probes (kernel
>>   version for testing program with kprobes is retrieved directly from
>>   libbpf).
>> - Dump one list of available helpers per program type (instead of one
>>   list of compatible program types per helper).
>>
>> v2:
>> - Move probes from bpftool to libbpf.
>> - Test all program types for each helper, print a list of working prog
>>   types for each helper.
>> - Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
>> - Remove C-style macros output from this patch.
>>
>> Signed-off-by: Quentin Monnet <quentin.monnet@...ronome.com>
>> ---
>>  .../bpftool/Documentation/bpftool-feature.rst |  4 ++
>>  tools/bpf/bpftool/feature.c                   | 49 +++++++++++++++
>>  tools/lib/bpf/libbpf.h                        |  2 +
>>  tools/lib/bpf/libbpf.map                      |  1 +
>>  tools/lib/bpf/libbpf_probes.c                 | 62 +++++++++++++++++++
>>  5 files changed, 118 insertions(+)
>>

>> diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h
>> index 72385f6f9415..6ab275933d2e 100644
>> --- a/tools/lib/bpf/libbpf.h
>> +++ b/tools/lib/bpf/libbpf.h
>> @@ -366,6 +366,8 @@ bpf_prog_linfo__lfind(const struct bpf_prog_linfo *prog_linfo,
>>  LIBBPF_API bool bpf_probe_prog_type(enum bpf_prog_type prog_type,
>>                                     __u32 ifindex);
>>  LIBBPF_API bool bpf_probe_map_type(enum bpf_map_type map_type, __u32 ifindex);
>> +LIBBPF_API bool bpf_probe_helper(__u32 id, enum bpf_prog_type prog_type,
> Any reason not to use enum bpf_func_id as id type (instead of __u32)?

No reason (other than me forgetting about that enum when writing the
function), I'll fix it, thanks!