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: <c3dd4327-bef1-16f6-7a73-20f981e1f538@netronome.com>
Date:   Thu, 20 Dec 2018 20:05:20 +0000
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Daniel Borkmann <daniel@...earbox.net>,
        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

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?

Thanks,
Quentin