Re: [PATCH bpf-next 3/8] tools: bpftool: add probes for kernel configuration options
From: Quentin Monnet <hidden>
Date: 2018-12-19 18:49:12
2018-12-15 03:32 UTC+0000 ~ Quentin Monnet [off-list ref]
2018-12-15 00:56 UTC+0100 ~ Daniel Borkmann [off-list ref]quoted
On 12/13/2018 01:19 PM, Quentin Monnet wrote:quoted
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?