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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH3MdRX+8Segzcxhc=Gu7qfZovXLRB5PUDj8RB0LV27n82MHRg@mail.gmail.com>
Date:   Fri, 4 Jan 2019 09:36:19 -0800
From:   Y Song <ys114321@...il.com>
To:     Quentin Monnet <quentin.monnet@...ronome.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

On Fri, Jan 4, 2019 at 6:27 AM Quentin Monnet
<quentin.monnet@...ronome.com> wrote:
>
> 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,

That is true. They are kind of independent for compilations.

> 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?

The following list should be a good start:
CONFIG_TRACING
CONFIG_KPROBE_EVENTS
CONFIG_UPROBE_EVENTS
CONFIG_BPF_EVENTS
CONFIG_FTRACE_SYSCALLS

No need for CONFIG_KPROBES and CONFIG_UPROBES which
are implied by CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS respectively,
and BPF mostly hooked to the events.

TRACING will enable tracepoint.
BPF_EVENTS depends on KPROBE_EVENTS or UPROBE_EVENTS, and PERF_EVENTS.
Having both CONFIG_KPROBE_EVENTS and CONFIG_UPROBE_EVENTS will tell
whether one of them or both are supported.
CONFIG_FTRACE_SYSCALLS needed to tell whether syscall tracepoints will
be supported or not
so bpf programs attached to these syscall tracepoints will work.

>
> Thanks,
> Quentin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ