netdev - Re: [RFC PATCH bpf-next v2 7/9] tools: bpftool: add C-style "#define" output for probes

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: <4146e01a-5755-a103-2b53-212e5c7faeb9@iogearbox.net>
Date:   Thu, 20 Dec 2018 18:25:25 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Quentin Monnet <quentin.monnet@...ronome.com>,
        Alexei Starovoitov <ast@...nel.org>
Cc:     netdev@...r.kernel.org, oss-drivers@...ronome.com,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Stanislav Fomichev <sdf@...gle.com>
Subject: Re: [RFC PATCH bpf-next v2 7/9] tools: bpftool: add C-style "#define"
 output for probes

On 12/20/2018 01:24 PM, Quentin Monnet wrote:
> Make bpftool able to dump a subset of the parameters collected by
> probing the system as a listing of C-style #define macros, so that
> external projects can reuse the result of this probing and build
> BPF-based project in accordance with the features available on the
> system.
> 
> The new "macros" keyword is used to select this output. An additional
> "prefix" keyword is added so that users can select a custom prefix for
> macro names, in order to avoid any namespace conflict.
> 
> Sample output:
> 
>     # bpftool feature probe kernel macros prefix FOO_
>     /*** System call availability ***/
>     #define FOO_HAVE_BPF_SYSCALL
> 
>     /*** eBPF program types ***/
>     #define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
>     #define FOO_HAVE_KPROBE_PROG_TYPE
>     #define FOO_HAVE_SCHED_CLS_PROG_TYPE
>     ...
> 
>     /*** eBPF map types ***/
>     #define FOO_HAVE_HASH_MAP_TYPE
>     #define FOO_HAVE_ARRAY_MAP_TYPE
>     #define FOO_HAVE_PROG_ARRAY_MAP_TYPE
>     ...
> 
>     /*** eBPF helper functions ***/
>     ...
>     #define FOO_BPF_SKB_CHANGE_HEAD_HELPER_COMPAT_LIST      ""      \
>             "lwt_xmit "     \
>             "sk_skb "
>     #define FOO_BPF_XDP_ADJUST_HEAD_HELPER_COMPAT_LIST      ""      \
>             "xdp "
>     #define FOO_BPF_PROBE_READ_STR_HELPER_COMPAT_LIST       ""      \
>             "kprobe "       \
>             "tracepoint "   \
>             "perf_event "   \
>             "raw_tracepoint "
>     ...

Rest looks good to me, just a comment here. How would programs use the
compat list? Wouldn't it be nicer to provide a PROG(HELPER) availability
query along the lines of ...

#if FOO_HAVE_SOCKET_FILTER(skb_load_bytes) == 1
// ...
#endif

... where the helper provides these macro functions and results in the
header file? So they can be used easily in the code from BPF prog or
normal C applications?

> v2:
> - #define-based output added as a distinct patch.
> - "HAVE_" prefix appended to all macro names.
> - Output limited to bpf() syscall availability, BPF prog and map types,
>   helper functions. In this version kernel config options, procfs
>   parameter or kernel version are intentionally left aside.
> - Following the change on helper probes, format for helper probes in
>   this output style has changed (now a list of compatible program
>   types).
> 
> Signed-off-by: Quentin Monnet <quentin.monnet@...ronome.com>