Subject: Re: [PATCH bpf-next 0/8] tools: bpftool: add probes for system and device

From: Arnaldo Carvalho de Melo <[email-masked]>
Date: Fri, 14 Dec 2018 11:00:09 -0300

Em Thu, Dec 13, 2018 at 12:19:14PM +0000, Quentin Monnet escreveu:
> Hi,
> This set add a new command to bpftool in order to dump a list of
> eBPF-related parameters for the system (or for a specific network
> device) to the console. Once again, this is based on a suggestion from
> Daniel.
> 
> At this time, output includes:
> 
>     - Availability of bpf() system call
>     - Availability of bpf() system call for unprivileged users
>     - JIT status (enabled or not, with or without debugging traces)
>     - JIT hardening status
>     - JIT kallsyms exports status
>     - Status of kernel compilation options related to BPF features
>     - Release number of the running kernel
>     - Availability of known eBPF program types
>     - Availability of known eBPF map types
>     - Availability of known eBPF helper functions
> 
> There are three different ways to dump this information at this time:
> 
>     - Plain output dumps probe results in plain text. It is the most
>       flexible options for providing descriptive output to the user, but
>       should not be relied upon for parsing the output.
>     - JSON output is supported.
>     - A third mode, available through the "macros" keyword appended to
>       the command line, dumps the parameters as a series of "#define"
>       directives, that can be included into a C header file for example.
> 
> If the user does not have root privileges (or more precisely, the
> CAP_SYS_ADMIN capability) detection will be erroneous for most
> parameters. Therefore, forbid non-root users to run the command.

One other thing I noticed is that this has lots of goodies that are not
bpftool specific, like the json writer, the procfs reading routines,
etc.

perf has these and some were even moved to tools/lib/api/, things like
finding the procfs, debugfs, sysfs mount points, routines to mount then
automatically when the user can do it, etc.

Have you considered using them? If so, what prevented you from doing it?
Licensing?

Sharing these non-tool specific routines in tools/lib/ is a good thing
and we should work out details on what prevents that from happening.

Another thing that came to mind is that the bpf loaded in perf has
routines for figuring out the kbuild directory, kernel version, etc.

Please take a look at tools/perf/util/llvm-utils.c and
tools/perf/util/bpf-loader.c. If we could reuse what is there, working
out licensing details with Wang, etc, that would be awesome.

- Arnaldo