| 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
| ||
|
Message-ID: <037a13ab-0c4a-5732-5025-a8866aa0485b@netronome.com>
Date: Fri, 4 Jan 2019 14:27:16 +0000
From: Quentin Monnet <quentin.monnet@...ronome.com>
To: Y Song <ys114321@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
netdev <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 bpf-next v3 3/9] tools: bpftool: add probes for kernel
configuration options
2019-01-03 22:35 UTC-0800 ~ Y Song <ys114321@...il.com>
> On Thu, Jan 3, 2019 at 9:27 AM Quentin Monnet
> <quentin.monnet@...ronome.com> 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",
>> ...
>> }
>> }
>>
>> v3:
>> - Add a comment about /proc/config.gz not being supported as a path for
>> the config file at this time.
>> - Use p_info() instead of p_err() on failure to get options from config
>> file, as bpftool keeps probing other parameters and that would
>> possibly create duplicate "error" entries for JSON.
>>
>> 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 | 142 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 142 insertions(+)
>>
>> diff --git a/tools/bpf/bpftool/feature.c b/tools/bpf/bpftool/feature.c
>> index 37fe79f59015..05c16fe67005 100644
>> --- a/tools/bpf/bpftool/feature.c
>> +++ b/tools/bpf/bpftool/feature.c
>> @@ -48,6 +48,30 @@ print_bool_feature(const char *feat_name, const char *plain_name, bool res)
>> printf("%s is %savailable\n", plain_name, res ? "" : "NOT ");
>> }
>>
>> +static void print_kernel_option(const char *name, const char *value)
>> +{
>> + char *endptr;
>> + int res;
>> +
>> + if (json_output) {
>> + if (!value) {
>> + jsonw_null_field(json_wtr, name);
>> + return;
>> + }
>> + errno = 0;
>> + res = strtol(value, &endptr, 0);
>> + if (!errno && *endptr == '\n')
>> + jsonw_int_field(json_wtr, name, res);
>> + else
>> + jsonw_string_field(json_wtr, name, value);
>> + } else {
>> + if (value)
>> + printf("%s is set to %s\n", name, value);
>> + else
>> + printf("%s is not set\n", name);
>> + }
>> +}
>> +
>> static void
>> print_start_section(const char *json_title, const char *plain_title)
>> {
>> @@ -190,6 +214,123 @@ static void probe_jit_kallsyms(void)
>> }
>> }
>>
>> +static char *get_kernel_config_option(FILE *fd, const char *option)
>> +{
>> + size_t line_n = 0, optlen = strlen(option);
>> + char *res, *strval, *line = NULL;
>> + ssize_t n;
>> +
>> + rewind(fd);
>> + while ((n = getline(&line, &line_n, fd)) > 0) {
>> + if (strncmp(line, option, optlen))
>> + continue;
>> + /* Check we have at least '=', value, and '\n' */
>> + if (strlen(line) < optlen + 3)
>> + continue;
>> + if (*(line + optlen) != '=')
>> + continue;
>> +
>> + /* Trim ending '\n' */
>> + line[strlen(line) - 1] = '\0';
>> +
>> + /* Copy and return config option value */
>> + strval = line + optlen + 1;
>> + res = strdup(strval);
>> + free(line);
>> + return res;
>> + }
>> + free(line);
>> +
>> + return NULL;
>> +}
>> +
>> +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",
>
> The list does not have any tracing specific configs like
> CONFIG_KPROBES, CONFIG_UPROBES, etc.
> Should we check those as well?
I didn't find any BPF items for which compiling would depend on those
options, that's why they are not in the list at the moment. But yeah,
they are definitely useful to tell if kprobe-attached programs have any
chance to work, so it would make sense I guess... What options do you
have in mind exactly? CONFIG_KPROBES and CONFIG_UPROBES, do you believe
CONFING_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS would also be relevant?
Thanks,
Quentin
Powered by blists - more mailing lists