2018-12-15 03:32 UTC+0000 ~ Quentin Monnet <quentin.mon...@netronome.com>
> 2018-12-15 00:56 UTC+0100 ~ Daniel Borkmann <dan...@iogearbox.net>
>> On 12/13/2018 01:19 PM, Quentin Monnet wrote:
>>> Add probes to dump a number of options set (or not set) for compiling
>>> the kernel image. These parameters provide information about what BPF
>>> components should be available on the system. A number of them are not
>>> directly related to eBPF, but are in fact used in the kernel as
>>> conditions on which to compile, or not to compile, some of the eBPF
>>> helper functions.
>>>
>>> Sample output:
>>>
>>> # bpftool feature probe kernel
>>> Scanning system configuration...
>>> ...
>>> CONFIG_BPF is set to y
>>> CONFIG_BPF_SYSCALL is set to y
>>> CONFIG_HAVE_EBPF_JIT is set to y
>>> ...
>>>
>>> # bpftool --pretty --json feature probe kernel
>>> {
>>> "system_config": {
>>> ...
>>> "CONFIG_BPF": "y",
>>> "CONFIG_BPF_SYSCALL": "y",
>>> "CONFIG_HAVE_EBPF_JIT": "y",
>>> ...
>>> }
>>> }
>>>
>>> # bpftool feature probe kernel macros prefix BPFTOOL_
>>> /*** System configuration ***/
>>> ...
>>> #define BPFTOOL_CONFIG_BPF y
>>> #define BPFTOOL_CONFIG_BPF_SYSCALL y
>>> #define BPFTOOL_CONFIG_HAVE_EBPF_JIT y
>>> ...
>>
>> Looks reasonable. I think as a user next question that would
>> follow-up from it would be whether this set of config means
>> that e.g. requirements for XDP, cgroups bpf, tracing or xyz is
>> fulfilled. Perhaps it makes sense to split the options[] into
>> base_options[], bpf_trace_options[], bpf_tc_options[] etc such
>> that it might become obvious that base_options[] + bpf_tc_options[]
>> are supported and thus cls_bpf could be used. I'd see this part
>> here in general more as giving a hint to the user in that some
>> basic assumptions could be made and providing some info on the
>> misc ones on what might potentially be missing. Though more
>> concrete info would come from the actual helper / map / prog
>> type probing.
>
> Good idea. I admit that the list of options dumped with no explanations
> whatsoever is hard to interpret. I'll try to divide the list into
> meaningful subsections.
Hi Daniel, I've been looking into this and I have some trouble figuring
out how to group those options. I could think of something like the
following:
base_options:
CONFIG_BPF
CONFIG_BPF_SYSCALL
jit_options:
CONFIG_HAVE_EBPF_JIT
CONFIG_BPF_JIT
CONFIG_BPF_JIT_ALWAYS_ON
events_options:
CONFIG_BPF_EVENTS
net_options:
CONFIG_NET
tc_options:
CONFIG_NET_ACT_BPF
CONFIG_NET_CLS_ACT
CONFIG_NET_CLS_BPF
CONFIG_NET_SCH_INGRESS
cgroup_options:
CONFIG_CGROUPS
CONFIG_CGROUP_BPF
CONFIG_CGROUP_NET_CLASSID
options for specific program types:
CONFIG_LWTUNNEL_BPF
CONFIG_XDP_SOCKETS
CONFIG_BPF_LIRC_MODE2
CONFIG_SOCK_CGROUP_DATA
CONFIG_IPV6_SEG6_BPF
CONFIG_BPF_STREAM_PARSER
options related to specific helpers:
CONFIG_IP_ROUTE_CLASSID (or in tc_options?)
CONFIG_XFRM
CONFIG_BPF_KPROBE_OVERRIDE (or in events_options?)
CONFIG_FUNCTION_ERROR_INJECTION (idem?)
bpf_misc:
CONFIG_NETFILTER_XT_MATCH_BPF
CONFIG_TEST_BPF
CONFIG_BPFILTER
CONFIG_BPFILTER_UMH
I'm not really sure how to group options for specific types (e.g.
CONFIG_LWTUNNEL_BPF), would they need one subsection each? What about
the options that are only required for some helpers but that do not
change the list of supported prog/map types? I could group them in
progtype_options and helper_options maybe.
Also the idea of checking base_options + net_options + tc_options does
not really provide precise information about whether tc_cls programs
should be supported (I mean on the theoretical, config-option side).
CONFIG_NET_CLS_ACT is not mandatory for example. Same thing for cgroups:
CONFIG_NET_CGROUP_NET_CLASSID is just needed for one helper, if I
remember correctly. Should I take it out of cgroup_options? I think it
would make sense keeping it in that group though, even if it makes this
kind of checks less accurate. Opinions?
