netdev - Re: [RFC PATCH bpf-next v2 3/9] 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:   Thu, 20 Dec 2018 18:02:12 +0000
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Stanislav Fomichev <sdf@...ichev.me>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, 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 3/9] tools: bpftool: add probes for kernel
 configuration options

2018-12-20 09:40 UTC-0800 ~ Stanislav Fomichev <sdf@...ichev.me>
> On 12/20, 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",
>>              ...
>>          }
>>      }
>>
>> v2:
>> - Remove C-style macros output from this patch.
>> - NOT addressed: grouping of those config options into subsections
>>    (I don't see an easy way of grouping them at the moment, please see
>>    also the discussion on v1 thread).
>>
>> Signed-off-by: Quentin Monnet <quentin.monnet@...ronome.com>
>> Reviewed-by: Jakub Kicinski <jakub.kicinski@...ronome.com>
>> ---
>>   tools/bpf/bpftool/feature.c | 137 ++++++++++++++++++++++++++++++++++++
>>   1 file changed, 137 insertions(+)

>> +static void probe_kernel_image_config(void)
>> +{
>> +	const char * const options[] = {
>> +		"CONFIG_BPF",
>> +		"CONFIG_BPF_SYSCALL",
>> +		"CONFIG_HAVE_EBPF_JIT",
>> +		"CONFIG_BPF_JIT",
>> +		"CONFIG_BPF_JIT_ALWAYS_ON",
>> +		"CONFIG_NET",
>> +		"CONFIG_XDP_SOCKETS",
>> +		"CONFIG_CGROUPS",
>> +		"CONFIG_CGROUP_BPF",
>> +		"CONFIG_CGROUP_NET_CLASSID",
>> +		"CONFIG_BPF_EVENTS",
>> +		"CONFIG_LWTUNNEL_BPF",
>> +		"CONFIG_NET_ACT_BPF",
>> +		"CONFIG_NET_CLS_ACT",
>> +		"CONFIG_NET_CLS_BPF",
>> +		"CONFIG_NET_SCH_INGRESS",
>> +		"CONFIG_XFRM",
>> +		"CONFIG_SOCK_CGROUP_DATA",
>> +		"CONFIG_IP_ROUTE_CLASSID",
>> +		"CONFIG_IPV6_SEG6_BPF",
>> +		"CONFIG_FUNCTION_ERROR_INJECTION",
>> +		"CONFIG_BPF_KPROBE_OVERRIDE",
>> +		"CONFIG_BPF_LIRC_MODE2",
>> +		"CONFIG_NETFILTER_XT_MATCH_BPF",
>> +		"CONFIG_TEST_BPF",
>> +		"CONFIG_BPFILTER",
>> +		"CONFIG_BPFILTER_UMH",
>> +		"CONFIG_BPF_STREAM_PARSER",
>> +	};
>> +	char *value, *buf = NULL;
>> +	struct utsname utsn;
>> +	char path[PATH_MAX];
>> +	size_t i, n;
>> +	ssize_t ret;
>> +	FILE *fd;
>> +
>> +	if (uname(&utsn))
>> +		goto no_config;
>> +
> [..]
>> +	snprintf(path, sizeof(path), "/boot/config-%s", utsn.release);
>> +
>> +	fd = fopen(path, "r");
>> +	if (!fd && errno == ENOENT) {
>> +		/* Sometimes config is at /proc/config */
>> +		fd = fopen("/proc/config", "r");
> I wonder whether the order here should be reversed?
> 1. try /proc/config.gz (CONFIG_IKCONFIG_PROC)
> 2. if not avail, try /boot/config-$(uname -r)
> 
> Because, at the end, /proc/config.gz is the real source of truth (if
> available).
> 
> What is /proc/config btw? I can see only /proc/config.gz being exported.

Hi Stanislav,

Cilium checks for /proc/config (apparently this is where CoreOS puts its 
config file), /proc/config.gz and /boot/config-$(uname -r) [0]. I took 
inspiration on that but didn't implement the /proc/config.gz file, 
because it would require linking with the libz and I'm not sure this is 
worth it. Could be added as a follow-up if necessary.

[0] https://github.com/cilium/cilium/blob/master/bpf/run_probes.sh#L42