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] [day] [month] [year] [list]

Message-ID: <795be966-1673-8a1f-5d7d-84fc60571f9a@iogearbox.net>
Date:   Thu, 20 Dec 2018 23:29:55 +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 09:05 PM, Quentin Monnet wrote:
> 2018-12-20 18:25 UTC+0100 ~ Daniel Borkmann <daniel@...earbox.net>
>> 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?
> 
> I was thinking about strstr() here, but it is true it is limited to runtime and will not work with the preprocessor :s.
> 
> How would you dump parameters to make your PROG(HELPER) work? Something along the following?
> 
>     #define BPF__PROG_TYPE_SOCKET_FILTER__HELPER_skb_load_bytes 1
>     #define BPF__PROG_TYPE_SOCKET_FILTER__HELPER_bind           0
>     ...
> 
>     #define HAVE_SOCKET_FILTER_HELPER(name) \
>         BPF__PROG_TYPE_SOCKET_FILTER__HELPER_ ## name
> 
> or even
> 
>     #define HAVE_PROG_TYPE_HELPER(type, helper) \
>         BPF__PROG_TYPE_ ## type ## __HELPER_ ## helper
> 
> Does that correspond to what you have in mind?

Yeah, something like this; slight preference to the latter.

Thanks,
Daniel