2019-01-17 15:27:50 +00:00
|
|
|
// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
|
|
|
/* Copyright (c) 2019 Netronome Systems, Inc. */
|
|
|
|
|
2019-01-17 15:27:53 +00:00
|
|
|
#include <ctype.h>
|
2019-01-17 15:27:50 +00:00
|
|
|
#include <errno.h>
|
|
|
|
#include <string.h>
|
|
|
|
#include <unistd.h>
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
#include <net/if.h>
|
2020-04-29 14:45:06 +00:00
|
|
|
#ifdef USE_LIBCAP
|
2020-04-29 14:45:05 +00:00
|
|
|
#include <sys/capability.h>
|
2020-04-29 14:45:06 +00:00
|
|
|
#endif
|
2019-01-17 15:27:50 +00:00
|
|
|
#include <sys/utsname.h>
|
2019-01-17 15:27:51 +00:00
|
|
|
#include <sys/vfs.h>
|
2019-01-17 15:27:50 +00:00
|
|
|
|
|
|
|
#include <linux/filter.h>
|
|
|
|
#include <linux/limits.h>
|
|
|
|
|
2020-01-20 13:06:46 +00:00
|
|
|
#include <bpf/bpf.h>
|
|
|
|
#include <bpf/libbpf.h>
|
2019-08-09 00:39:11 +00:00
|
|
|
#include <zlib.h>
|
2019-01-17 15:27:50 +00:00
|
|
|
|
|
|
|
#include "main.h"
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
#ifndef PROC_SUPER_MAGIC
|
|
|
|
# define PROC_SUPER_MAGIC 0x9fa0
|
|
|
|
#endif
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
enum probe_component {
|
|
|
|
COMPONENT_UNSPEC,
|
|
|
|
COMPONENT_KERNEL,
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
COMPONENT_DEVICE,
|
2019-01-17 15:27:50 +00:00
|
|
|
};
|
|
|
|
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
#define BPF_HELPER_MAKE_ENTRY(name) [BPF_FUNC_ ## name] = "bpf_" # name
|
|
|
|
static const char * const helper_name[] = {
|
|
|
|
__BPF_FUNC_MAPPER(BPF_HELPER_MAKE_ENTRY)
|
|
|
|
};
|
|
|
|
|
|
|
|
#undef BPF_HELPER_MAKE_ENTRY
|
|
|
|
|
2020-04-29 14:45:04 +00:00
|
|
|
static bool full_mode;
|
2020-04-29 14:45:06 +00:00
|
|
|
#ifdef USE_LIBCAP
|
2020-04-29 14:45:05 +00:00
|
|
|
static bool run_as_unprivileged;
|
2020-04-29 14:45:06 +00:00
|
|
|
#endif
|
2020-04-29 14:45:04 +00:00
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
/* Miscellaneous utility functions */
|
|
|
|
|
|
|
|
static bool check_procfs(void)
|
|
|
|
{
|
|
|
|
struct statfs st_fs;
|
|
|
|
|
|
|
|
if (statfs("/proc", &st_fs) < 0)
|
|
|
|
return false;
|
|
|
|
if ((unsigned long)st_fs.f_type != PROC_SUPER_MAGIC)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
static void uppercase(char *str, size_t len)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < len && str[i] != '\0'; i++)
|
|
|
|
str[i] = toupper(str[i]);
|
|
|
|
}
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
/* Printing utility functions */
|
|
|
|
|
|
|
|
static void
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
print_bool_feature(const char *feat_name, const char *plain_name,
|
|
|
|
const char *define_name, bool res, const char *define_prefix)
|
2019-01-17 15:27:50 +00:00
|
|
|
{
|
|
|
|
if (json_output)
|
|
|
|
jsonw_bool_field(json_wtr, feat_name, res);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
else if (define_prefix)
|
|
|
|
printf("#define %s%sHAVE_%s\n", define_prefix,
|
|
|
|
res ? "" : "NO_", define_name);
|
2019-01-17 15:27:50 +00:00
|
|
|
else
|
|
|
|
printf("%s is %savailable\n", plain_name, res ? "" : "NOT ");
|
|
|
|
}
|
|
|
|
|
2020-05-13 07:58:49 +00:00
|
|
|
static void print_kernel_option(const char *name, const char *value,
|
|
|
|
const char *define_prefix)
|
2019-01-17 15:27:52 +00:00
|
|
|
{
|
|
|
|
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);
|
2020-05-13 07:58:49 +00:00
|
|
|
} else if (define_prefix) {
|
|
|
|
if (value)
|
|
|
|
printf("#define %s%s %s\n", define_prefix,
|
|
|
|
name, value);
|
|
|
|
else
|
|
|
|
printf("/* %s%s is not set */\n", define_prefix, name);
|
2019-01-17 15:27:52 +00:00
|
|
|
} else {
|
|
|
|
if (value)
|
|
|
|
printf("%s is set to %s\n", name, value);
|
|
|
|
else
|
|
|
|
printf("%s is not set\n", name);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
static void
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
print_start_section(const char *json_title, const char *plain_title,
|
|
|
|
const char *define_comment, const char *define_prefix)
|
2019-01-17 15:27:50 +00:00
|
|
|
{
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_name(json_wtr, json_title);
|
|
|
|
jsonw_start_object(json_wtr);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
} else if (define_prefix) {
|
|
|
|
printf("%s\n", define_comment);
|
2019-01-17 15:27:50 +00:00
|
|
|
} else {
|
|
|
|
printf("%s\n", plain_title);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2020-02-26 16:59:35 +00:00
|
|
|
static void print_end_section(void)
|
2019-01-17 15:27:53 +00:00
|
|
|
{
|
|
|
|
if (json_output)
|
|
|
|
jsonw_end_object(json_wtr);
|
|
|
|
else
|
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
/* Probing functions */
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
static int read_procfs(const char *path)
|
|
|
|
{
|
|
|
|
char *endptr, *line = NULL;
|
|
|
|
size_t len = 0;
|
|
|
|
FILE *fd;
|
|
|
|
int res;
|
|
|
|
|
|
|
|
fd = fopen(path, "r");
|
|
|
|
if (!fd)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
res = getline(&line, &len, fd);
|
|
|
|
fclose(fd);
|
|
|
|
if (res < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
res = strtol(line, &endptr, 10);
|
|
|
|
if (errno || *line == '\0' || *endptr != '\n')
|
|
|
|
res = -1;
|
|
|
|
free(line);
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void probe_unprivileged_disabled(void)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
/* No support for C-style ouptut */
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
res = read_procfs("/proc/sys/kernel/unprivileged_bpf_disabled");
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_int_field(json_wtr, "unprivileged_bpf_disabled", res);
|
|
|
|
} else {
|
|
|
|
switch (res) {
|
|
|
|
case 0:
|
|
|
|
printf("bpf() syscall for unprivileged users is enabled\n");
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
printf("bpf() syscall restricted to privileged users\n");
|
|
|
|
break;
|
|
|
|
case -1:
|
|
|
|
printf("Unable to retrieve required privileges for bpf() syscall\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("bpf() syscall restriction has unknown value %d\n", res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void probe_jit_enable(void)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
/* No support for C-style ouptut */
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
res = read_procfs("/proc/sys/net/core/bpf_jit_enable");
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_int_field(json_wtr, "bpf_jit_enable", res);
|
|
|
|
} else {
|
|
|
|
switch (res) {
|
|
|
|
case 0:
|
|
|
|
printf("JIT compiler is disabled\n");
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
printf("JIT compiler is enabled\n");
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
printf("JIT compiler is enabled with debugging traces in kernel logs\n");
|
|
|
|
break;
|
|
|
|
case -1:
|
|
|
|
printf("Unable to retrieve JIT-compiler status\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("JIT-compiler status has unknown value %d\n",
|
|
|
|
res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void probe_jit_harden(void)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
/* No support for C-style ouptut */
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
res = read_procfs("/proc/sys/net/core/bpf_jit_harden");
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_int_field(json_wtr, "bpf_jit_harden", res);
|
|
|
|
} else {
|
|
|
|
switch (res) {
|
|
|
|
case 0:
|
|
|
|
printf("JIT compiler hardening is disabled\n");
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
printf("JIT compiler hardening is enabled for unprivileged users\n");
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
printf("JIT compiler hardening is enabled for all users\n");
|
|
|
|
break;
|
|
|
|
case -1:
|
|
|
|
printf("Unable to retrieve JIT hardening status\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("JIT hardening status has unknown value %d\n",
|
|
|
|
res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void probe_jit_kallsyms(void)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
/* No support for C-style ouptut */
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
res = read_procfs("/proc/sys/net/core/bpf_jit_kallsyms");
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_int_field(json_wtr, "bpf_jit_kallsyms", res);
|
|
|
|
} else {
|
|
|
|
switch (res) {
|
|
|
|
case 0:
|
|
|
|
printf("JIT compiler kallsyms exports are disabled\n");
|
|
|
|
break;
|
|
|
|
case 1:
|
|
|
|
printf("JIT compiler kallsyms exports are enabled for root\n");
|
|
|
|
break;
|
|
|
|
case -1:
|
|
|
|
printf("Unable to retrieve JIT kallsyms export status\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("JIT kallsyms exports status has unknown value %d\n", res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void probe_jit_limit(void)
|
|
|
|
{
|
|
|
|
int res;
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
/* No support for C-style ouptut */
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
res = read_procfs("/proc/sys/net/core/bpf_jit_limit");
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_int_field(json_wtr, "bpf_jit_limit", res);
|
|
|
|
} else {
|
|
|
|
switch (res) {
|
|
|
|
case -1:
|
|
|
|
printf("Unable to retrieve global memory limit for JIT compiler for unprivileged users\n");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printf("Global memory limit for JIT compiler for unprivileged users is %d bytes\n", res);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
static bool read_next_kernel_config_option(gzFile file, char *buf, size_t n,
|
|
|
|
char **value)
|
2019-01-17 15:27:52 +00:00
|
|
|
{
|
2019-08-09 00:39:11 +00:00
|
|
|
char *sep;
|
2019-01-17 15:27:52 +00:00
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
while (gzgets(file, buf, n)) {
|
|
|
|
if (strncmp(buf, "CONFIG_", 7))
|
2019-01-17 15:27:52 +00:00
|
|
|
continue;
|
2019-08-09 00:39:11 +00:00
|
|
|
|
|
|
|
sep = strchr(buf, '=');
|
|
|
|
if (!sep)
|
2019-01-17 15:27:52 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Trim ending '\n' */
|
2019-08-09 00:39:11 +00:00
|
|
|
buf[strlen(buf) - 1] = '\0';
|
|
|
|
|
|
|
|
/* Split on '=' and ensure that a value is present. */
|
|
|
|
*sep = '\0';
|
|
|
|
if (!sep[1])
|
|
|
|
continue;
|
2019-01-17 15:27:52 +00:00
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
*value = sep + 1;
|
|
|
|
return true;
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
return false;
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
|
2020-05-13 07:58:49 +00:00
|
|
|
static void probe_kernel_image_config(const char *define_prefix)
|
2019-01-17 15:27:52 +00:00
|
|
|
{
|
2020-05-13 07:58:49 +00:00
|
|
|
static const struct {
|
|
|
|
const char * const name;
|
|
|
|
bool macro_dump;
|
|
|
|
} options[] = {
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Enable BPF */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Enable bpf() syscall */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_SYSCALL", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Does selected architecture support eBPF JIT compiler */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_HAVE_EBPF_JIT", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Compile eBPF JIT compiler */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_JIT", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Avoid compiling eBPF interpreter (use JIT only) */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_JIT_ALWAYS_ON", },
|
2021-02-22 19:58:46 +00:00
|
|
|
/* Kernel BTF debug information available */
|
|
|
|
{ "CONFIG_DEBUG_INFO_BTF", },
|
|
|
|
/* Kernel module BTF debug information available */
|
|
|
|
{ "CONFIG_DEBUG_INFO_BTF_MODULES", },
|
2019-01-17 15:27:52 +00:00
|
|
|
|
|
|
|
/* cgroups */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_CGROUPS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF programs attached to cgroups */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_CGROUP_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpf_get_cgroup_classid() helper */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_CGROUP_NET_CLASSID", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpf_skb_{,ancestor_}cgroup_id() helpers */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_SOCK_CGROUP_DATA", },
|
2019-01-17 15:27:52 +00:00
|
|
|
|
|
|
|
/* Tracing: attach BPF to kprobes, tracepoints, etc. */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_EVENTS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Kprobes */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_KPROBE_EVENTS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Uprobes */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_UPROBE_EVENTS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Tracepoints */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_TRACING", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Syscall tracepoints */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_FTRACE_SYSCALLS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpf_override_return() helper support for selected arch */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_FUNCTION_ERROR_INJECTION", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpf_override_return() helper */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_KPROBE_OVERRIDE", },
|
2019-01-17 15:27:52 +00:00
|
|
|
|
|
|
|
/* Network */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_NET", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* AF_XDP sockets */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_XDP_SOCKETS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF_PROG_TYPE_LWT_* and related helpers */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_LWTUNNEL_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF_PROG_TYPE_SCHED_ACT, TC (traffic control) actions */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_NET_ACT_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF_PROG_TYPE_SCHED_CLS, TC filters */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_NET_CLS_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* TC clsact qdisc */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_NET_CLS_ACT", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* Ingress filtering with TC */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_NET_SCH_INGRESS", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpf_skb_get_xfrm_state() helper */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_XFRM", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpf_get_route_realm() helper */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_IP_ROUTE_CLASSID", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF_PROG_TYPE_LWT_SEG6_LOCAL and related helpers */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_IPV6_SEG6_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF_PROG_TYPE_LIRC_MODE2 and related helpers */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_LIRC_MODE2", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* BPF stream parser and BPF socket maps */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPF_STREAM_PARSER", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* xt_bpf module for passing BPF programs to netfilter */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_NETFILTER_XT_MATCH_BPF", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpfilter back-end for iptables */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPFILTER", },
|
2019-01-17 15:27:52 +00:00
|
|
|
/* bpftilter module with "user mode helper" */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_BPFILTER_UMH", },
|
2019-01-17 15:27:52 +00:00
|
|
|
|
|
|
|
/* test_bpf module for BPF tests */
|
2020-05-13 07:58:49 +00:00
|
|
|
{ "CONFIG_TEST_BPF", },
|
|
|
|
|
|
|
|
/* Misc configs useful in BPF C programs */
|
|
|
|
/* jiffies <-> sec conversion for bpf_jiffies64() helper */
|
|
|
|
{ "CONFIG_HZ", true, }
|
2019-01-17 15:27:52 +00:00
|
|
|
};
|
2019-08-09 00:39:11 +00:00
|
|
|
char *values[ARRAY_SIZE(options)] = { };
|
2019-01-17 15:27:52 +00:00
|
|
|
struct utsname utsn;
|
|
|
|
char path[PATH_MAX];
|
2019-08-09 00:39:11 +00:00
|
|
|
gzFile file = NULL;
|
|
|
|
char buf[4096];
|
|
|
|
char *value;
|
|
|
|
size_t i;
|
2019-01-17 15:27:52 +00:00
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
if (!uname(&utsn)) {
|
|
|
|
snprintf(path, sizeof(path), "/boot/config-%s", utsn.release);
|
2019-01-17 15:27:52 +00:00
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
/* gzopen also accepts uncompressed files. */
|
|
|
|
file = gzopen(path, "r");
|
|
|
|
}
|
2019-01-17 15:27:52 +00:00
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
if (!file) {
|
|
|
|
/* Some distributions build with CONFIG_IKCONFIG=y and put the
|
|
|
|
* config file at /proc/config.gz.
|
2019-01-17 15:27:52 +00:00
|
|
|
*/
|
2019-08-09 00:39:11 +00:00
|
|
|
file = gzopen("/proc/config.gz", "r");
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
2019-08-09 00:39:11 +00:00
|
|
|
if (!file) {
|
2019-01-17 15:27:52 +00:00
|
|
|
p_info("skipping kernel config, can't open file: %s",
|
|
|
|
strerror(errno));
|
2019-08-09 00:39:11 +00:00
|
|
|
goto end_parse;
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
/* Sanity checks */
|
2019-08-09 00:39:11 +00:00
|
|
|
if (!gzgets(file, buf, sizeof(buf)) ||
|
|
|
|
!gzgets(file, buf, sizeof(buf))) {
|
2019-01-17 15:27:52 +00:00
|
|
|
p_info("skipping kernel config, can't read from file: %s",
|
|
|
|
strerror(errno));
|
2019-08-09 00:39:11 +00:00
|
|
|
goto end_parse;
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
if (strcmp(buf, "# Automatically generated file; DO NOT EDIT.\n")) {
|
|
|
|
p_info("skipping kernel config, can't find correct file");
|
2019-08-09 00:39:11 +00:00
|
|
|
goto end_parse;
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
while (read_next_kernel_config_option(file, buf, sizeof(buf), &value)) {
|
|
|
|
for (i = 0; i < ARRAY_SIZE(options); i++) {
|
2020-05-13 07:58:49 +00:00
|
|
|
if ((define_prefix && !options[i].macro_dump) ||
|
|
|
|
values[i] || strcmp(buf, options[i].name))
|
2019-08-09 00:39:11 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
values[i] = strdup(value);
|
|
|
|
}
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
|
2019-08-09 00:39:11 +00:00
|
|
|
end_parse:
|
|
|
|
if (file)
|
|
|
|
gzclose(file);
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(options); i++) {
|
2020-05-13 07:58:49 +00:00
|
|
|
if (define_prefix && !options[i].macro_dump)
|
|
|
|
continue;
|
|
|
|
print_kernel_option(options[i].name, values[i], define_prefix);
|
2019-08-09 00:39:11 +00:00
|
|
|
free(values[i]);
|
|
|
|
}
|
2019-01-17 15:27:52 +00:00
|
|
|
}
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
static bool probe_bpf_syscall(const char *define_prefix)
|
2019-01-17 15:27:50 +00:00
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
|
|
|
|
bpf_load_program(BPF_PROG_TYPE_UNSPEC, NULL, 0, NULL, 0, NULL, 0);
|
|
|
|
res = (errno != ENOSYS);
|
|
|
|
|
|
|
|
print_bool_feature("have_bpf_syscall",
|
|
|
|
"bpf() syscall",
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
"BPF_SYSCALL",
|
|
|
|
res, define_prefix);
|
2019-01-17 15:27:50 +00:00
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
static void
|
|
|
|
probe_prog_type(enum bpf_prog_type prog_type, bool *supported_types,
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
const char *define_prefix, __u32 ifindex)
|
2019-01-17 15:27:53 +00:00
|
|
|
{
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
char feat_name[128], plain_desc[128], define_name[128];
|
2019-01-17 15:27:53 +00:00
|
|
|
const char *plain_comment = "eBPF program_type ";
|
|
|
|
size_t maxlen;
|
|
|
|
bool res;
|
|
|
|
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
if (ifindex)
|
|
|
|
/* Only test offload-able program types */
|
|
|
|
switch (prog_type) {
|
|
|
|
case BPF_PROG_TYPE_SCHED_CLS:
|
|
|
|
case BPF_PROG_TYPE_XDP:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
res = bpf_probe_prog_type(prog_type, ifindex);
|
2020-04-29 14:45:06 +00:00
|
|
|
#ifdef USE_LIBCAP
|
2020-04-29 14:45:05 +00:00
|
|
|
/* Probe may succeed even if program load fails, for unprivileged users
|
|
|
|
* check that we did not fail because of insufficient permissions
|
|
|
|
*/
|
|
|
|
if (run_as_unprivileged && errno == EPERM)
|
|
|
|
res = false;
|
2020-04-29 14:45:06 +00:00
|
|
|
#endif
|
2019-01-17 15:27:53 +00:00
|
|
|
|
|
|
|
supported_types[prog_type] |= res;
|
|
|
|
|
2020-07-24 09:06:17 +00:00
|
|
|
if (!prog_type_name[prog_type]) {
|
|
|
|
p_info("program type name not found (type %d)", prog_type);
|
|
|
|
return;
|
|
|
|
}
|
2019-01-17 15:27:53 +00:00
|
|
|
maxlen = sizeof(plain_desc) - strlen(plain_comment) - 1;
|
|
|
|
if (strlen(prog_type_name[prog_type]) > maxlen) {
|
|
|
|
p_info("program type name too long");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
sprintf(feat_name, "have_%s_prog_type", prog_type_name[prog_type]);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
sprintf(define_name, "%s_prog_type", prog_type_name[prog_type]);
|
|
|
|
uppercase(define_name, sizeof(define_name));
|
2019-01-17 15:27:53 +00:00
|
|
|
sprintf(plain_desc, "%s%s", plain_comment, prog_type_name[prog_type]);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
print_bool_feature(feat_name, plain_desc, define_name, res,
|
|
|
|
define_prefix);
|
2019-01-17 15:27:53 +00:00
|
|
|
}
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
static void
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
probe_map_type(enum bpf_map_type map_type, const char *define_prefix,
|
|
|
|
__u32 ifindex)
|
2019-01-17 15:27:54 +00:00
|
|
|
{
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
char feat_name[128], plain_desc[128], define_name[128];
|
2019-01-17 15:27:54 +00:00
|
|
|
const char *plain_comment = "eBPF map_type ";
|
|
|
|
size_t maxlen;
|
|
|
|
bool res;
|
|
|
|
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
res = bpf_probe_map_type(map_type, ifindex);
|
2019-01-17 15:27:54 +00:00
|
|
|
|
2020-04-29 14:45:05 +00:00
|
|
|
/* Probe result depends on the success of map creation, no additional
|
|
|
|
* check required for unprivileged users
|
|
|
|
*/
|
|
|
|
|
2020-07-24 09:06:17 +00:00
|
|
|
if (!map_type_name[map_type]) {
|
|
|
|
p_info("map type name not found (type %d)", map_type);
|
|
|
|
return;
|
|
|
|
}
|
2019-01-17 15:27:54 +00:00
|
|
|
maxlen = sizeof(plain_desc) - strlen(plain_comment) - 1;
|
|
|
|
if (strlen(map_type_name[map_type]) > maxlen) {
|
|
|
|
p_info("map type name too long");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
sprintf(feat_name, "have_%s_map_type", map_type_name[map_type]);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
sprintf(define_name, "%s_map_type", map_type_name[map_type]);
|
|
|
|
uppercase(define_name, sizeof(define_name));
|
2019-01-17 15:27:54 +00:00
|
|
|
sprintf(plain_desc, "%s%s", plain_comment, map_type_name[map_type]);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
print_bool_feature(feat_name, plain_desc, define_name, res,
|
|
|
|
define_prefix);
|
2019-01-17 15:27:54 +00:00
|
|
|
}
|
|
|
|
|
2020-02-26 16:59:36 +00:00
|
|
|
static void
|
|
|
|
probe_helper_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
|
|
|
|
const char *define_prefix, unsigned int id,
|
|
|
|
const char *ptype_name, __u32 ifindex)
|
|
|
|
{
|
2020-04-29 14:45:05 +00:00
|
|
|
bool res = false;
|
2020-02-26 16:59:36 +00:00
|
|
|
|
2020-04-29 14:45:05 +00:00
|
|
|
if (supported_type) {
|
2020-02-26 16:59:36 +00:00
|
|
|
res = bpf_probe_helper(id, prog_type, ifindex);
|
2020-04-29 14:45:06 +00:00
|
|
|
#ifdef USE_LIBCAP
|
2020-04-29 14:45:05 +00:00
|
|
|
/* Probe may succeed even if program load fails, for
|
|
|
|
* unprivileged users check that we did not fail because of
|
|
|
|
* insufficient permissions
|
|
|
|
*/
|
|
|
|
if (run_as_unprivileged && errno == EPERM)
|
|
|
|
res = false;
|
2020-04-29 14:45:06 +00:00
|
|
|
#endif
|
2020-04-29 14:45:05 +00:00
|
|
|
}
|
2020-02-26 16:59:36 +00:00
|
|
|
|
|
|
|
if (json_output) {
|
|
|
|
if (res)
|
|
|
|
jsonw_string(json_wtr, helper_name[id]);
|
|
|
|
} else if (define_prefix) {
|
|
|
|
printf("#define %sBPF__PROG_TYPE_%s__HELPER_%s %s\n",
|
|
|
|
define_prefix, ptype_name, helper_name[id],
|
|
|
|
res ? "1" : "0");
|
|
|
|
} else {
|
|
|
|
if (res)
|
|
|
|
printf("\n\t- %s", helper_name[id]);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
static void
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
probe_helpers_for_progtype(enum bpf_prog_type prog_type, bool supported_type,
|
2020-04-29 14:45:04 +00:00
|
|
|
const char *define_prefix, __u32 ifindex)
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
{
|
|
|
|
const char *ptype_name = prog_type_name[prog_type];
|
|
|
|
char feat_name[128];
|
|
|
|
unsigned int id;
|
|
|
|
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
if (ifindex)
|
|
|
|
/* Only test helpers for offload-able program types */
|
|
|
|
switch (prog_type) {
|
|
|
|
case BPF_PROG_TYPE_SCHED_CLS:
|
|
|
|
case BPF_PROG_TYPE_XDP:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
if (json_output) {
|
|
|
|
sprintf(feat_name, "%s_available_helpers", ptype_name);
|
|
|
|
jsonw_name(json_wtr, feat_name);
|
|
|
|
jsonw_start_array(json_wtr);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
} else if (!define_prefix) {
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
printf("eBPF helpers supported for program type %s:",
|
|
|
|
ptype_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
for (id = 1; id < ARRAY_SIZE(helper_name); id++) {
|
2020-02-26 16:59:36 +00:00
|
|
|
/* Skip helper functions which emit dmesg messages when not in
|
|
|
|
* the full mode.
|
|
|
|
*/
|
|
|
|
switch (id) {
|
|
|
|
case BPF_FUNC_trace_printk:
|
2021-09-17 18:29:08 +00:00
|
|
|
case BPF_FUNC_trace_vprintk:
|
2020-02-26 16:59:36 +00:00
|
|
|
case BPF_FUNC_probe_write_user:
|
|
|
|
if (!full_mode)
|
|
|
|
continue;
|
|
|
|
/* fallthrough */
|
|
|
|
default:
|
|
|
|
probe_helper_for_progtype(prog_type, supported_type,
|
|
|
|
define_prefix, id, ptype_name,
|
|
|
|
ifindex);
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_end_array(json_wtr);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
else if (!define_prefix)
|
tools: bpftool: add probes for eBPF helper functions
Similarly to what was done for program types and map types, add a set of
probes to test the availability of the different eBPF helper functions
on the current system.
For each known program type, all known helpers are tested, in order to
establish a compatibility matrix. Output is provided as a set of lists
of available helpers, one per program type.
Sample output:
# bpftool feature probe kernel
...
Scanning eBPF helper functions...
eBPF helpers supported for program type socket_filter:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
eBPF helpers supported for program type kprobe:
- bpf_map_lookup_elem
- bpf_map_update_elem
- bpf_map_delete_elem
...
# bpftool --json --pretty feature probe kernel
{
...
"helpers": {
"socket_filter_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
"kprobe_available_helpers": ["bpf_map_lookup_elem", \
"bpf_map_update_elem","bpf_map_delete_elem", ...
],
...
}
}
v5:
- In libbpf.map, move global symbol to the new LIBBPF_0.0.2 section.
v4:
- Use "enum bpf_func_id" instead of "__u32" in bpf_probe_helper()
declaration for the type of the argument used to pass the id of
the helper to probe.
- Undef BPF_HELPER_MAKE_ENTRY after using it.
v3:
- Do not pass kernel version from bpftool to libbpf probes (kernel
version for testing program with kprobes is retrieved directly from
libbpf).
- Dump one list of available helpers per program type (instead of one
list of compatible program types per helper).
v2:
- Move probes from bpftool to libbpf.
- Test all program types for each helper, print a list of working prog
types for each helper.
- Fall back on include/uapi/linux/bpf.h for names and ids of helpers.
- Remove C-style macros output from this patch.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:55 +00:00
|
|
|
printf("\n");
|
|
|
|
}
|
|
|
|
|
2020-01-08 16:23:53 +00:00
|
|
|
static void
|
|
|
|
probe_large_insn_limit(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
|
|
|
|
res = bpf_probe_large_insn_limit(ifindex);
|
|
|
|
print_bool_feature("have_large_insn_limit",
|
|
|
|
"Large program size limit",
|
2020-02-02 11:02:00 +00:00
|
|
|
"LARGE_INSN_LIMIT",
|
2020-01-08 16:23:53 +00:00
|
|
|
res, define_prefix);
|
|
|
|
}
|
|
|
|
|
2020-02-26 16:59:35 +00:00
|
|
|
static void
|
|
|
|
section_system_config(enum probe_component target, const char *define_prefix)
|
|
|
|
{
|
|
|
|
switch (target) {
|
|
|
|
case COMPONENT_KERNEL:
|
|
|
|
case COMPONENT_UNSPEC:
|
|
|
|
print_start_section("system_config",
|
|
|
|
"Scanning system configuration...",
|
2020-05-13 07:58:49 +00:00
|
|
|
"/*** Misc kernel config items ***/",
|
|
|
|
define_prefix);
|
|
|
|
if (!define_prefix) {
|
|
|
|
if (check_procfs()) {
|
|
|
|
probe_unprivileged_disabled();
|
|
|
|
probe_jit_enable();
|
|
|
|
probe_jit_harden();
|
|
|
|
probe_jit_kallsyms();
|
|
|
|
probe_jit_limit();
|
|
|
|
} else {
|
|
|
|
p_info("/* procfs not mounted, skipping related probes */");
|
|
|
|
}
|
2020-02-26 16:59:35 +00:00
|
|
|
}
|
2020-05-13 07:58:49 +00:00
|
|
|
probe_kernel_image_config(define_prefix);
|
2020-02-26 16:59:35 +00:00
|
|
|
print_end_section();
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool section_syscall_config(const char *define_prefix)
|
|
|
|
{
|
|
|
|
bool res;
|
|
|
|
|
|
|
|
print_start_section("syscall_config",
|
|
|
|
"Scanning system call availability...",
|
|
|
|
"/*** System call availability ***/",
|
|
|
|
define_prefix);
|
|
|
|
res = probe_bpf_syscall(define_prefix);
|
|
|
|
print_end_section();
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
section_program_types(bool *supported_types, const char *define_prefix,
|
|
|
|
__u32 ifindex)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
print_start_section("program_types",
|
|
|
|
"Scanning eBPF program types...",
|
|
|
|
"/*** eBPF program types ***/",
|
|
|
|
define_prefix);
|
|
|
|
|
2020-06-24 14:31:24 +00:00
|
|
|
for (i = BPF_PROG_TYPE_UNSPEC + 1; i < prog_type_name_size; i++)
|
2020-02-26 16:59:35 +00:00
|
|
|
probe_prog_type(i, supported_types, define_prefix, ifindex);
|
|
|
|
|
|
|
|
print_end_section();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void section_map_types(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
print_start_section("map_types",
|
|
|
|
"Scanning eBPF map types...",
|
|
|
|
"/*** eBPF map types ***/",
|
|
|
|
define_prefix);
|
|
|
|
|
|
|
|
for (i = BPF_MAP_TYPE_UNSPEC + 1; i < map_type_name_size; i++)
|
|
|
|
probe_map_type(i, define_prefix, ifindex);
|
|
|
|
|
|
|
|
print_end_section();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2020-04-29 14:45:04 +00:00
|
|
|
section_helpers(bool *supported_types, const char *define_prefix, __u32 ifindex)
|
2020-02-26 16:59:35 +00:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
print_start_section("helpers",
|
|
|
|
"Scanning eBPF helper functions...",
|
|
|
|
"/*** eBPF helper functions ***/",
|
|
|
|
define_prefix);
|
|
|
|
|
|
|
|
if (define_prefix)
|
|
|
|
printf("/*\n"
|
|
|
|
" * Use %sHAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)\n"
|
|
|
|
" * to determine if <helper_name> is available for <prog_type_name>,\n"
|
|
|
|
" * e.g.\n"
|
|
|
|
" * #if %sHAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)\n"
|
|
|
|
" * // do stuff with this helper\n"
|
|
|
|
" * #elif\n"
|
|
|
|
" * // use a workaround\n"
|
|
|
|
" * #endif\n"
|
|
|
|
" */\n"
|
|
|
|
"#define %sHAVE_PROG_TYPE_HELPER(prog_type, helper) \\\n"
|
|
|
|
" %sBPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper\n",
|
|
|
|
define_prefix, define_prefix, define_prefix,
|
|
|
|
define_prefix);
|
2020-06-24 14:31:24 +00:00
|
|
|
for (i = BPF_PROG_TYPE_UNSPEC + 1; i < prog_type_name_size; i++)
|
2020-04-29 14:45:04 +00:00
|
|
|
probe_helpers_for_progtype(i, supported_types[i], define_prefix,
|
|
|
|
ifindex);
|
2020-02-26 16:59:35 +00:00
|
|
|
|
|
|
|
print_end_section();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void section_misc(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
|
|
|
print_start_section("misc",
|
|
|
|
"Scanning miscellaneous eBPF features...",
|
|
|
|
"/*** eBPF misc features ***/",
|
|
|
|
define_prefix);
|
|
|
|
probe_large_insn_limit(define_prefix, ifindex);
|
|
|
|
print_end_section();
|
|
|
|
}
|
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
#ifdef USE_LIBCAP
|
|
|
|
#define capability(c) { c, false, #c }
|
|
|
|
#define capability_msg(a, i) a[i].set ? "" : a[i].name, a[i].set ? "" : ", "
|
|
|
|
#endif
|
|
|
|
|
2020-04-29 14:45:05 +00:00
|
|
|
static int handle_perms(void)
|
|
|
|
{
|
2020-04-29 14:45:06 +00:00
|
|
|
#ifdef USE_LIBCAP
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
struct {
|
|
|
|
cap_value_t cap;
|
|
|
|
bool set;
|
|
|
|
char name[14]; /* strlen("CAP_SYS_ADMIN") */
|
|
|
|
} bpf_caps[] = {
|
|
|
|
capability(CAP_SYS_ADMIN),
|
|
|
|
#ifdef CAP_BPF
|
|
|
|
capability(CAP_BPF),
|
|
|
|
capability(CAP_NET_ADMIN),
|
|
|
|
capability(CAP_PERFMON),
|
|
|
|
#endif
|
|
|
|
};
|
|
|
|
cap_value_t cap_list[ARRAY_SIZE(bpf_caps)];
|
|
|
|
unsigned int i, nb_bpf_caps = 0;
|
|
|
|
bool cap_sys_admin_only = true;
|
2020-04-29 14:45:05 +00:00
|
|
|
cap_flag_value_t val;
|
|
|
|
int res = -1;
|
|
|
|
cap_t caps;
|
|
|
|
|
|
|
|
caps = cap_get_proc();
|
|
|
|
if (!caps) {
|
|
|
|
p_err("failed to get capabilities for process: %s",
|
|
|
|
strerror(errno));
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
#ifdef CAP_BPF
|
|
|
|
if (CAP_IS_SUPPORTED(CAP_BPF))
|
|
|
|
cap_sys_admin_only = false;
|
|
|
|
#endif
|
2020-04-29 14:45:05 +00:00
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
for (i = 0; i < ARRAY_SIZE(bpf_caps); i++) {
|
|
|
|
const char *cap_name = bpf_caps[i].name;
|
|
|
|
cap_value_t cap = bpf_caps[i].cap;
|
|
|
|
|
|
|
|
if (cap_get_flag(caps, cap, CAP_EFFECTIVE, &val)) {
|
|
|
|
p_err("bug: failed to retrieve %s status: %s", cap_name,
|
|
|
|
strerror(errno));
|
|
|
|
goto exit_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (val == CAP_SET) {
|
|
|
|
bpf_caps[i].set = true;
|
|
|
|
cap_list[nb_bpf_caps++] = cap;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cap_sys_admin_only)
|
|
|
|
/* System does not know about CAP_BPF, meaning that
|
|
|
|
* CAP_SYS_ADMIN is the only capability required. We
|
|
|
|
* just checked it, break.
|
|
|
|
*/
|
|
|
|
break;
|
2020-04-29 14:45:05 +00:00
|
|
|
}
|
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
if ((run_as_unprivileged && !nb_bpf_caps) ||
|
|
|
|
(!run_as_unprivileged && nb_bpf_caps == ARRAY_SIZE(bpf_caps)) ||
|
|
|
|
(!run_as_unprivileged && cap_sys_admin_only && nb_bpf_caps)) {
|
2020-04-29 14:45:05 +00:00
|
|
|
/* We are all good, exit now */
|
|
|
|
res = 0;
|
|
|
|
goto exit_free;
|
|
|
|
}
|
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
if (!run_as_unprivileged) {
|
|
|
|
if (cap_sys_admin_only)
|
|
|
|
p_err("missing %s, required for full feature probing; run as root or use 'unprivileged'",
|
|
|
|
bpf_caps[0].name);
|
|
|
|
else
|
|
|
|
p_err("missing %s%s%s%s%s%s%s%srequired for full feature probing; run as root or use 'unprivileged'",
|
|
|
|
capability_msg(bpf_caps, 0),
|
2020-10-27 23:36:45 +00:00
|
|
|
#ifdef CAP_BPF
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
capability_msg(bpf_caps, 1),
|
|
|
|
capability_msg(bpf_caps, 2),
|
2020-10-27 23:36:45 +00:00
|
|
|
capability_msg(bpf_caps, 3)
|
|
|
|
#else
|
|
|
|
"", "", "", "", "", ""
|
|
|
|
#endif /* CAP_BPF */
|
|
|
|
);
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
goto exit_free;
|
|
|
|
}
|
2020-04-29 14:45:05 +00:00
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
/* if (run_as_unprivileged && nb_bpf_caps > 0), drop capabilities. */
|
|
|
|
if (cap_set_flag(caps, CAP_EFFECTIVE, nb_bpf_caps, cap_list,
|
2020-04-29 14:45:05 +00:00
|
|
|
CAP_CLEAR)) {
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
p_err("bug: failed to clear capabilities: %s", strerror(errno));
|
2020-04-29 14:45:05 +00:00
|
|
|
goto exit_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cap_set_proc(caps)) {
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
p_err("failed to drop capabilities: %s", strerror(errno));
|
2020-04-29 14:45:05 +00:00
|
|
|
goto exit_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
res = 0;
|
|
|
|
|
|
|
|
exit_free:
|
|
|
|
if (cap_free(caps) && !res) {
|
|
|
|
p_err("failed to clear storage object for capabilities: %s",
|
|
|
|
strerror(errno));
|
|
|
|
res = -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
2020-04-29 14:45:06 +00:00
|
|
|
#else
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
/* Detection assumes user has specific privileges.
|
2020-04-29 14:45:06 +00:00
|
|
|
* We do not use libpcap so let's approximate, and restrict usage to
|
|
|
|
* root user only.
|
|
|
|
*/
|
|
|
|
if (geteuid()) {
|
|
|
|
p_err("full feature probing requires root privileges");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
#endif /* USE_LIBCAP */
|
2020-04-29 14:45:05 +00:00
|
|
|
}
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
static int do_probe(int argc, char **argv)
|
|
|
|
{
|
|
|
|
enum probe_component target = COMPONENT_UNSPEC;
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
const char *define_prefix = NULL;
|
2019-01-17 15:27:53 +00:00
|
|
|
bool supported_types[128] = {};
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
__u32 ifindex = 0;
|
|
|
|
char *ifname;
|
2019-01-17 15:27:50 +00:00
|
|
|
|
|
|
|
set_max_rlimit();
|
|
|
|
|
|
|
|
while (argc) {
|
|
|
|
if (is_prefix(*argv, "kernel")) {
|
|
|
|
if (target != COMPONENT_UNSPEC) {
|
|
|
|
p_err("component to probe already specified");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
target = COMPONENT_KERNEL;
|
|
|
|
NEXT_ARG();
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
} else if (is_prefix(*argv, "dev")) {
|
|
|
|
NEXT_ARG();
|
|
|
|
|
|
|
|
if (target != COMPONENT_UNSPEC || ifindex) {
|
|
|
|
p_err("component to probe already specified");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (!REQ_ARGS(1))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
target = COMPONENT_DEVICE;
|
|
|
|
ifname = GET_ARG();
|
|
|
|
ifindex = if_nametoindex(ifname);
|
|
|
|
if (!ifindex) {
|
|
|
|
p_err("unrecognized netdevice '%s': %s", ifname,
|
|
|
|
strerror(errno));
|
|
|
|
return -1;
|
|
|
|
}
|
2020-02-26 16:59:36 +00:00
|
|
|
} else if (is_prefix(*argv, "full")) {
|
|
|
|
full_mode = true;
|
|
|
|
NEXT_ARG();
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
} else if (is_prefix(*argv, "macros") && !define_prefix) {
|
|
|
|
define_prefix = "";
|
|
|
|
NEXT_ARG();
|
|
|
|
} else if (is_prefix(*argv, "prefix")) {
|
|
|
|
if (!define_prefix) {
|
|
|
|
p_err("'prefix' argument can only be use after 'macros'");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
if (strcmp(define_prefix, "")) {
|
|
|
|
p_err("'prefix' already defined");
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
NEXT_ARG();
|
|
|
|
|
|
|
|
if (!REQ_ARGS(1))
|
|
|
|
return -1;
|
|
|
|
define_prefix = GET_ARG();
|
2020-04-29 14:45:05 +00:00
|
|
|
} else if (is_prefix(*argv, "unprivileged")) {
|
2020-04-29 14:45:06 +00:00
|
|
|
#ifdef USE_LIBCAP
|
2020-04-29 14:45:05 +00:00
|
|
|
run_as_unprivileged = true;
|
|
|
|
NEXT_ARG();
|
2020-04-29 14:45:06 +00:00
|
|
|
#else
|
|
|
|
p_err("unprivileged run not supported, recompile bpftool with libcap");
|
|
|
|
return -1;
|
|
|
|
#endif
|
2019-01-17 15:27:50 +00:00
|
|
|
} else {
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
p_err("expected no more arguments, 'kernel', 'dev', 'macros' or 'prefix', got: '%s'?",
|
2019-01-17 15:27:50 +00:00
|
|
|
*argv);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
tools, bpftool: Make capability check account for new BPF caps
Following the introduction of CAP_BPF, and the switch from CAP_SYS_ADMIN
to other capabilities for various BPF features, update the capability
checks (and potentially, drops) in bpftool for feature probes. Because
bpftool and/or the system might not know of CAP_BPF yet, some caution is
necessary:
- If compiled and run on a system with CAP_BPF, check CAP_BPF,
CAP_SYS_ADMIN, CAP_PERFMON, CAP_NET_ADMIN.
- Guard against CAP_BPF being undefined, to allow compiling bpftool from
latest sources on older systems. If the system where feature probes
are run does not know of CAP_BPF, stop checking after CAP_SYS_ADMIN,
as this should be the only capability required for all the BPF
probing.
- If compiled from latest sources on a system without CAP_BPF, but later
executed on a newer system with CAP_BPF knowledge, then we only test
CAP_SYS_ADMIN. Some probes may fail if the bpftool process has
CAP_SYS_ADMIN but misses the other capabilities. The alternative would
be to redefine the value for CAP_BPF in bpftool, but this does not
look clean, and the case sounds relatively rare anyway.
Note that libcap offers a cap_to_name() function to retrieve the name of
a given capability (e.g. "cap_sys_admin"). We do not use it because
deriving the names from the macros looks simpler than using
cap_to_name() (doing a strdup() on the string) + cap_free() + handling
the case of failed allocations, when we just want to use the name of the
capability in an error message.
The checks when compiling without libcap (i.e. root versus non-root) are
unchanged.
v2:
- Do not allocate cap_list dynamically.
- Drop BPF-related capabilities when running with "unprivileged", even
if we didn't have the full set in the first place (in v1, we would
skip dropping them in that case).
- Keep track of what capabilities we have, print the names of the
missing ones for privileged probing.
- Attempt to drop only the capabilities we actually have.
- Rename a couple variables.
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20200523010247.20654-1-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2020-05-23 01:02:47 +00:00
|
|
|
/* Full feature detection requires specific privileges.
|
2020-04-29 14:45:05 +00:00
|
|
|
* Let's approximate, and warn if user is not root.
|
|
|
|
*/
|
|
|
|
if (handle_perms())
|
|
|
|
return -1;
|
|
|
|
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
if (json_output) {
|
|
|
|
define_prefix = NULL;
|
2019-01-17 15:27:50 +00:00
|
|
|
jsonw_start_object(json_wtr);
|
tools: bpftool: add C-style "#define" output for probes
Make bpftool able to dump a subset of the parameters collected by
probing the system as a listing of C-style #define macros, so that
external projects can reuse the result of this probing and build
BPF-based project in accordance with the features available on the
system.
The new "macros" keyword is used to select this output. An additional
"prefix" keyword is added so that users can select a custom prefix for
macro names, in order to avoid any namespace conflict.
Sample output:
# bpftool feature probe kernel macros prefix FOO_
/*** System call availability ***/
#define FOO_HAVE_BPF_SYSCALL
/*** eBPF program types ***/
#define FOO_HAVE_SOCKET_FILTER_PROG_TYPE
#define FOO_HAVE_KPROBE_PROG_TYPE
#define FOO_HAVE_SCHED_CLS_PROG_TYPE
...
/*** eBPF map types ***/
#define FOO_HAVE_HASH_MAP_TYPE
#define FOO_HAVE_ARRAY_MAP_TYPE
#define FOO_HAVE_PROG_ARRAY_MAP_TYPE
...
/*** eBPF helper functions ***/
/*
* Use FOO_HAVE_PROG_TYPE_HELPER(prog_type_name, helper_name)
* to determine if <helper_name> is available for <prog_type_name>,
* e.g.
* #if FOO_HAVE_PROG_TYPE_HELPER(xdp, bpf_redirect)
* // do stuff with this helper
* #elif
* // use a workaround
* #endif
*/
#define FOO_HAVE_PROG_TYPE_HELPER(prog_type, helper) \
FOO_BPF__PROG_TYPE_ ## prog_type ## __HELPER_ ## helper
...
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_probe_read 0
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_ktime_get_ns 1
#define FOO_BPF__PROG_TYPE_socket_filter__HELPER_bpf_trace_printk 1
...
v3:
- Change output for helpers again: add a
HAVE_PROG_TYPE_HELPER(type, helper) macro that can be used to tell
if <helper> is available for program <type>.
v2:
- #define-based output added as a distinct patch.
- "HAVE_" prefix appended to macro names.
- Output limited to bpf() syscall availability, BPF prog and map types,
helper functions. In this version kernel config options, procfs
parameter or kernel version are intentionally left aside.
- Following the change on helper probes, format for helper probes in
this output style has changed (now a list of compatible program
types).
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:56 +00:00
|
|
|
}
|
2019-01-17 15:27:50 +00:00
|
|
|
|
2020-02-26 16:59:35 +00:00
|
|
|
section_system_config(target, define_prefix);
|
|
|
|
if (!section_syscall_config(define_prefix))
|
2019-01-17 15:27:53 +00:00
|
|
|
/* bpf() syscall unavailable, don't probe other BPF features */
|
|
|
|
goto exit_close_json;
|
2020-02-26 16:59:35 +00:00
|
|
|
section_program_types(supported_types, define_prefix, ifindex);
|
|
|
|
section_map_types(define_prefix, ifindex);
|
2020-04-29 14:45:04 +00:00
|
|
|
section_helpers(supported_types, define_prefix, ifindex);
|
2020-02-26 16:59:35 +00:00
|
|
|
section_misc(define_prefix, ifindex);
|
2020-01-08 16:23:53 +00:00
|
|
|
|
2019-01-17 15:27:53 +00:00
|
|
|
exit_close_json:
|
2020-02-26 16:59:35 +00:00
|
|
|
if (json_output)
|
2019-01-17 15:27:50 +00:00
|
|
|
/* End root object */
|
|
|
|
jsonw_end_object(json_wtr);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int do_help(int argc, char **argv)
|
|
|
|
{
|
|
|
|
if (json_output) {
|
|
|
|
jsonw_null(json_wtr);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
fprintf(stderr,
|
2020-05-23 01:07:51 +00:00
|
|
|
"Usage: %1$s %2$s probe [COMPONENT] [full] [unprivileged] [macros [prefix PREFIX]]\n"
|
|
|
|
" %1$s %2$s help\n"
|
tools: bpftool: add probes for a network device
bpftool gained support for probing the current system in order to see
what program and map types, and what helpers are available on that
system. This patch adds the possibility to pass an interface index to
libbpf (and hence to the kernel) when trying to load the programs or to
create the maps, in order to see what items a given network device can
support.
A new keyword "dev <ifname>" can be used as an alternative to "kernel"
to indicate that the given device should be tested. If no target ("dev"
or "kernel") is specified bpftool defaults to probing the kernel.
Sample output:
# bpftool -p feature probe dev lo
{
"syscall_config": {
"have_bpf_syscall": true
},
"program_types": {
"have_sched_cls_prog_type": false,
"have_xdp_prog_type": false
},
...
}
As the target is a network device, /proc/ parameters and kernel
configuration are NOT dumped. Availability of the bpf() syscall is
still probed, so we can return early if that syscall is not usable
(since there is no point in attempting the remaining probes in this
case).
Among the program types, only the ones that can be offloaded are probed.
All map types are probed, as there is no specific rule telling which one
could or could not be supported by a device in the future. All helpers
are probed (but only for offload-able program types).
Caveat: as bpftool does not attempt to attach programs to the device at
the moment, probes do not entirely reflect what the device accepts:
typically, for Netronome's nfp, results will announce that TC cls
offload is available even if support has been deactivated (with e.g.
ethtool -K eth1 hw-tc-offload off).
v2:
- All helpers are probed, whereas previous version would only probe the
ones compatible with an offload-able program type. This is because we
do not keep a default compatible program type for each helper anymore.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-01-17 15:27:57 +00:00
|
|
|
"\n"
|
|
|
|
" COMPONENT := { kernel | dev NAME }\n"
|
2021-07-30 21:54:32 +00:00
|
|
|
" " HELP_SPEC_OPTIONS " }\n"
|
2019-01-17 15:27:50 +00:00
|
|
|
"",
|
2020-05-23 01:07:51 +00:00
|
|
|
bin_name, argv[-2]);
|
2019-01-17 15:27:50 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct cmd cmds[] = {
|
|
|
|
{ "probe", do_probe },
|
2019-01-24 02:51:57 +00:00
|
|
|
{ "help", do_help },
|
2019-01-17 15:27:50 +00:00
|
|
|
{ 0 }
|
|
|
|
};
|
|
|
|
|
|
|
|
int do_feature(int argc, char **argv)
|
|
|
|
{
|
|
|
|
return cmd_select(cmds, argc, argv, do_help);
|
|
|
|
}
|