netdev - Re: [PATCH bpf-next 3/8] tools: bpftool: add probes for kernel configuration options

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]

Date:   Wed, 19 Dec 2018 18:49:07 +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: [PATCH bpf-next 3/8] tools: bpftool: add probes for kernel
 configuration options

2018-12-15 03:32 UTC+0000 ~ Quentin Monnet <quentin.monnet@...ronome.com>
> 2018-12-15 00:56 UTC+0100 ~ Daniel Borkmann <daniel@...earbox.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?