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>
|
2022-03-10 12:18:46 +00:00
|
|
|
#include <fcntl.h>
|
2019-01-17 15:27:50 +00:00
|
|
|
#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 */
|
|
|
|
|
2022-03-10 12:18:46 +00:00
|
|
|
static bool grep(const char *buffer, const char *pattern)
|
|
|
|
{
|
|
|
|
return !!strstr(buffer, pattern);
|
|
|
|
}
|
|
|
|
|
2019-01-17 15:27:51 +00:00
|
|
|
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 */
|
|
|
|
|
2022-03-10 12:18:46 +00:00
|
|
|
static int get_vendor_id(int ifindex)
|
|
|
|
{
|
|
|
|
char ifname[IF_NAMESIZE], path[64], buf[8];
|
|
|
|
ssize_t len;
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
if (!if_indextoname(ifindex, ifname))
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
snprintf(path, sizeof(path), "/sys/class/net/%s/device/vendor", ifname);
|
|
|
|
|
|
|
|
fd = open(path, O_RDONLY | O_CLOEXEC);
|
|
|
|
if (fd < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
len = read(fd, buf, sizeof(buf));
|
|
|
|
close(fd);
|
|
|
|
if (len < 0)
|
|
|
|
return -1;
|
|
|
|
if (len >= (ssize_t)sizeof(buf))
|
|
|
|
return -1;
|
|
|
|
buf[len] = '\0';
|
|
|
|
|
|
|
|
return strtol(buf, NULL, 0);
|
|
|
|
}
|
|
|
|
|
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:
|
2022-03-22 14:49:45 +00:00
|
|
|
printf("bpf() syscall restricted to privileged users (without recovery)\n");
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
printf("bpf() syscall restricted to privileged users (admin can change)\n");
|
2019-01-17 15:27:51 +00:00
|
|
|
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;
|
|
|
|
|
2021-11-03 22:08:39 +00:00
|
|
|
bpf_prog_load(BPF_PROG_TYPE_UNSPEC, NULL, NULL, NULL, 0, NULL);
|
2019-01-17 15:27:50 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2022-03-10 12:18:46 +00:00
|
|
|
static bool
|
|
|
|
probe_prog_load_ifindex(enum bpf_prog_type prog_type,
|
|
|
|
const struct bpf_insn *insns, size_t insns_cnt,
|
|
|
|
char *log_buf, size_t log_buf_sz,
|
|
|
|
__u32 ifindex)
|
|
|
|
{
|
|
|
|
LIBBPF_OPTS(bpf_prog_load_opts, opts,
|
|
|
|
.log_buf = log_buf,
|
|
|
|
.log_size = log_buf_sz,
|
|
|
|
.log_level = log_buf ? 1 : 0,
|
|
|
|
.prog_ifindex = ifindex,
|
|
|
|
);
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
fd = bpf_prog_load(prog_type, NULL, "GPL", insns, insns_cnt, &opts);
|
|
|
|
if (fd >= 0)
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
return fd >= 0 && errno != EINVAL && errno != EOPNOTSUPP;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool probe_prog_type_ifindex(enum bpf_prog_type prog_type, __u32 ifindex)
|
|
|
|
{
|
|
|
|
/* nfp returns -EINVAL on exit(0) with TC offload */
|
|
|
|
struct bpf_insn insns[2] = {
|
|
|
|
BPF_MOV64_IMM(BPF_REG_0, 2),
|
|
|
|
BPF_EXIT_INSN()
|
|
|
|
};
|
|
|
|
|
|
|
|
return probe_prog_load_ifindex(prog_type, insns, ARRAY_SIZE(insns),
|
|
|
|
NULL, 0, ifindex);
|
|
|
|
}
|
|
|
|
|
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
|
2022-05-23 23:04:19 +00:00
|
|
|
probe_prog_type(enum bpf_prog_type prog_type, const char *prog_type_str,
|
|
|
|
bool *supported_types, 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;
|
|
|
|
|
2022-02-02 22:59:12 +00:00
|
|
|
if (ifindex) {
|
2022-03-10 12:18:46 +00:00
|
|
|
switch (prog_type) {
|
|
|
|
case BPF_PROG_TYPE_SCHED_CLS:
|
|
|
|
case BPF_PROG_TYPE_XDP:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
res = probe_prog_type_ifindex(prog_type, ifindex);
|
|
|
|
} else {
|
2022-03-31 15:45:55 +00:00
|
|
|
res = libbpf_probe_bpf_prog_type(prog_type, NULL) > 0;
|
2022-02-02 22:59:12 +00:00
|
|
|
}
|
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
|
|
|
|
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;
|
|
|
|
|
|
|
|
maxlen = sizeof(plain_desc) - strlen(plain_comment) - 1;
|
2022-05-23 23:04:19 +00:00
|
|
|
if (strlen(prog_type_str) > maxlen) {
|
2019-01-17 15:27:53 +00:00
|
|
|
p_info("program type name too long");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-05-23 23:04:19 +00:00
|
|
|
sprintf(feat_name, "have_%s_prog_type", prog_type_str);
|
|
|
|
sprintf(define_name, "%s_prog_type", prog_type_str);
|
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
|
|
|
uppercase(define_name, sizeof(define_name));
|
2022-05-23 23:04:19 +00:00
|
|
|
sprintf(plain_desc, "%s%s", plain_comment, prog_type_str);
|
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
|
|
|
}
|
|
|
|
|
2022-03-10 12:18:46 +00:00
|
|
|
static bool probe_map_type_ifindex(enum bpf_map_type map_type, __u32 ifindex)
|
|
|
|
{
|
|
|
|
LIBBPF_OPTS(bpf_map_create_opts, opts);
|
|
|
|
int key_size, value_size, max_entries;
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
opts.map_ifindex = ifindex;
|
|
|
|
|
|
|
|
key_size = sizeof(__u32);
|
|
|
|
value_size = sizeof(__u32);
|
|
|
|
max_entries = 1;
|
|
|
|
|
|
|
|
fd = bpf_map_create(map_type, NULL, key_size, value_size, max_entries,
|
|
|
|
&opts);
|
|
|
|
if (fd >= 0)
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
return fd >= 0;
|
|
|
|
}
|
|
|
|
|
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
|
2022-05-23 23:04:22 +00:00
|
|
|
probe_map_type(enum bpf_map_type map_type, char const *map_type_str,
|
|
|
|
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;
|
|
|
|
|
2022-02-02 22:59:12 +00:00
|
|
|
if (ifindex) {
|
2022-03-10 12:18:46 +00:00
|
|
|
switch (map_type) {
|
|
|
|
case BPF_MAP_TYPE_HASH:
|
|
|
|
case BPF_MAP_TYPE_ARRAY:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return;
|
|
|
|
}
|
2022-02-02 22:59:12 +00:00
|
|
|
|
2022-03-10 12:18:46 +00:00
|
|
|
res = probe_map_type_ifindex(map_type, ifindex);
|
|
|
|
} else {
|
2022-05-04 16:13:31 +00:00
|
|
|
res = libbpf_probe_bpf_map_type(map_type, NULL) > 0;
|
2022-03-10 12:18:46 +00:00
|
|
|
}
|
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
|
|
|
|
*/
|
|
|
|
|
2019-01-17 15:27:54 +00:00
|
|
|
maxlen = sizeof(plain_desc) - strlen(plain_comment) - 1;
|
2022-05-23 23:04:22 +00:00
|
|
|
if (strlen(map_type_str) > maxlen) {
|
2019-01-17 15:27:54 +00:00
|
|
|
p_info("map type name too long");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2022-05-23 23:04:22 +00:00
|
|
|
sprintf(feat_name, "have_%s_map_type", map_type_str);
|
|
|
|
sprintf(define_name, "%s_map_type", map_type_str);
|
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
|
|
|
uppercase(define_name, sizeof(define_name));
|
2022-05-23 23:04:22 +00:00
|
|
|
sprintf(plain_desc, "%s%s", plain_comment, map_type_str);
|
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
|
|
|
}
|
|
|
|
|
2022-03-10 12:18:46 +00:00
|
|
|
static bool
|
|
|
|
probe_helper_ifindex(enum bpf_func_id id, enum bpf_prog_type prog_type,
|
|
|
|
__u32 ifindex)
|
|
|
|
{
|
|
|
|
struct bpf_insn insns[2] = {
|
|
|
|
BPF_EMIT_CALL(id),
|
|
|
|
BPF_EXIT_INSN()
|
|
|
|
};
|
|
|
|
char buf[4096] = {};
|
|
|
|
bool res;
|
|
|
|
|
|
|
|
probe_prog_load_ifindex(prog_type, insns, ARRAY_SIZE(insns), buf,
|
|
|
|
sizeof(buf), ifindex);
|
|
|
|
res = !grep(buf, "invalid func ") && !grep(buf, "unknown func ");
|
|
|
|
|
|
|
|
switch (get_vendor_id(ifindex)) {
|
|
|
|
case 0x19ee: /* Netronome specific */
|
|
|
|
res = res && !grep(buf, "not supported by FW") &&
|
|
|
|
!grep(buf, "unsupported function id");
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return res;
|
|
|
|
}
|
|
|
|
|
2022-05-04 16:13:32 +00:00
|
|
|
static bool
|
2020-02-26 16:59:36 +00:00
|
|
|
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) {
|
2022-03-10 12:18:46 +00:00
|
|
|
if (ifindex)
|
|
|
|
res = probe_helper_ifindex(id, prog_type, ifindex);
|
|
|
|
else
|
2022-05-04 16:13:31 +00:00
|
|
|
res = libbpf_probe_bpf_helper(prog_type, id, NULL) > 0;
|
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]);
|
|
|
|
}
|
2022-05-04 16:13:32 +00:00
|
|
|
|
|
|
|
return res;
|
2020-02-26 16:59:36 +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
|
|
|
static void
|
2022-05-23 23:04:19 +00:00
|
|
|
probe_helpers_for_progtype(enum bpf_prog_type prog_type,
|
|
|
|
const char *prog_type_str, 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
|
|
|
{
|
|
|
|
char feat_name[128];
|
|
|
|
unsigned int id;
|
2022-05-04 16:13:32 +00:00
|
|
|
bool probe_res = false;
|
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
|
|
|
|
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) {
|
2022-05-23 23:04:19 +00:00
|
|
|
sprintf(feat_name, "%s_available_helpers", prog_type_str);
|
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
|
|
|
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:",
|
2022-05-23 23:04:19 +00:00
|
|
|
prog_type_str);
|
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
|
|
|
}
|
|
|
|
|
|
|
|
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:
|
2022-05-04 16:13:32 +00:00
|
|
|
probe_res |= probe_helper_for_progtype(prog_type, supported_type,
|
2022-05-23 23:04:19 +00:00
|
|
|
define_prefix, id, prog_type_str,
|
2020-02-26 16:59:36 +00:00
|
|
|
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);
|
2022-05-04 16:13:32 +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");
|
2022-05-04 16:13:32 +00:00
|
|
|
if (!probe_res) {
|
|
|
|
if (!supported_type)
|
|
|
|
printf("\tProgram type not supported\n");
|
|
|
|
else
|
|
|
|
printf("\tCould not determine which helpers are available\n");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2022-01-04 17:59:29 +00:00
|
|
|
static void
|
|
|
|
probe_misc_feature(struct bpf_insn *insns, size_t len,
|
|
|
|
const char *define_prefix, __u32 ifindex,
|
|
|
|
const char *feat_name, const char *plain_name,
|
|
|
|
const char *define_name)
|
|
|
|
{
|
|
|
|
LIBBPF_OPTS(bpf_prog_load_opts, opts,
|
|
|
|
.prog_ifindex = ifindex,
|
|
|
|
);
|
|
|
|
bool res;
|
|
|
|
int fd;
|
|
|
|
|
|
|
|
errno = 0;
|
|
|
|
fd = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, NULL, "GPL",
|
|
|
|
insns, len, &opts);
|
|
|
|
res = fd >= 0 || !errno;
|
|
|
|
|
|
|
|
if (fd >= 0)
|
|
|
|
close(fd);
|
|
|
|
|
|
|
|
print_bool_feature(feat_name, plain_name, define_name, res,
|
|
|
|
define_prefix);
|
|
|
|
}
|
|
|
|
|
2021-12-17 17:12:02 +00:00
|
|
|
/*
|
|
|
|
* Probe for availability of kernel commit (5.3):
|
|
|
|
*
|
|
|
|
* c04c0d2b968a ("bpf: increase complexity limit and maximum program size")
|
|
|
|
*/
|
|
|
|
static void probe_large_insn_limit(const char *define_prefix, __u32 ifindex)
|
2020-01-08 16:23:53 +00:00
|
|
|
{
|
2021-12-17 17:12:02 +00:00
|
|
|
struct bpf_insn insns[BPF_MAXINSNS + 1];
|
2022-01-04 17:59:29 +00:00
|
|
|
int i;
|
2021-12-17 17:12:02 +00:00
|
|
|
|
|
|
|
for (i = 0; i < BPF_MAXINSNS; i++)
|
|
|
|
insns[i] = BPF_MOV64_IMM(BPF_REG_0, 1);
|
|
|
|
insns[BPF_MAXINSNS] = BPF_EXIT_INSN();
|
|
|
|
|
2022-01-04 17:59:29 +00:00
|
|
|
probe_misc_feature(insns, ARRAY_SIZE(insns),
|
|
|
|
define_prefix, ifindex,
|
|
|
|
"have_large_insn_limit",
|
2020-01-08 16:23:53 +00:00
|
|
|
"Large program size limit",
|
2022-01-04 17:59:29 +00:00
|
|
|
"LARGE_INSN_LIMIT");
|
2020-01-08 16:23:53 +00:00
|
|
|
}
|
|
|
|
|
2022-01-04 17:59:57 +00:00
|
|
|
/*
|
|
|
|
* Probe for bounded loop support introduced in commit 2589726d12a1
|
|
|
|
* ("bpf: introduce bounded loops").
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
probe_bounded_loops(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
|
|
|
struct bpf_insn insns[4] = {
|
|
|
|
BPF_MOV64_IMM(BPF_REG_0, 10),
|
|
|
|
BPF_ALU64_IMM(BPF_SUB, BPF_REG_0, 1),
|
|
|
|
BPF_JMP_IMM(BPF_JNE, BPF_REG_0, 0, -2),
|
|
|
|
BPF_EXIT_INSN()
|
|
|
|
};
|
|
|
|
|
|
|
|
probe_misc_feature(insns, ARRAY_SIZE(insns),
|
|
|
|
define_prefix, ifindex,
|
|
|
|
"have_bounded_loops",
|
|
|
|
"Bounded loop support",
|
|
|
|
"BOUNDED_LOOPS");
|
|
|
|
}
|
|
|
|
|
bpftool: Probe for instruction set extensions
This patch introduces new probes to check whether the kernel supports
instruction set extensions v2 and v3. The first introduced eBPF
instructions BPF_J{LT,LE,SLT,SLE} in commit 92b31a9af73b ("bpf: add
BPF_J{LT,LE,SLT,SLE} instructions"). The second introduces 32-bit
variants of all jump instructions in commit 092ed0968bb6 ("bpf:
verifier support JMP32").
These probes are useful for userspace BPF projects that want to use newer
instruction set extensions on newer kernels, to reduce the programs'
sizes or their complexity. LLVM already provides an mcpu=probe option to
automatically probe the kernel and select the newest-supported
instruction set extension. That is however not flexible enough for all
use cases. For example, in Cilium, we only want to use the v3
instruction set extension on v5.10+, even though it is supported on all
kernels v5.1+.
Signed-off-by: Paul Chaignon <paul@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/3bfedcd9898c1f41ac67ca61f144fec84c6c3a92.1641314075.git.paul@isovalent.com
2022-01-04 18:00:13 +00:00
|
|
|
/*
|
|
|
|
* Probe for the v2 instruction set extension introduced in commit 92b31a9af73b
|
|
|
|
* ("bpf: add BPF_J{LT,LE,SLT,SLE} instructions").
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
probe_v2_isa_extension(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
|
|
|
struct bpf_insn insns[4] = {
|
|
|
|
BPF_MOV64_IMM(BPF_REG_0, 0),
|
|
|
|
BPF_JMP_IMM(BPF_JLT, BPF_REG_0, 0, 1),
|
|
|
|
BPF_MOV64_IMM(BPF_REG_0, 1),
|
|
|
|
BPF_EXIT_INSN()
|
|
|
|
};
|
|
|
|
|
|
|
|
probe_misc_feature(insns, ARRAY_SIZE(insns),
|
|
|
|
define_prefix, ifindex,
|
|
|
|
"have_v2_isa_extension",
|
|
|
|
"ISA extension v2",
|
|
|
|
"V2_ISA_EXTENSION");
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Probe for the v3 instruction set extension introduced in commit 092ed0968bb6
|
|
|
|
* ("bpf: verifier support JMP32").
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
probe_v3_isa_extension(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
|
|
|
struct bpf_insn insns[4] = {
|
|
|
|
BPF_MOV64_IMM(BPF_REG_0, 0),
|
|
|
|
BPF_JMP32_IMM(BPF_JLT, BPF_REG_0, 0, 1),
|
|
|
|
BPF_MOV64_IMM(BPF_REG_0, 1),
|
|
|
|
BPF_EXIT_INSN()
|
|
|
|
};
|
|
|
|
|
|
|
|
probe_misc_feature(insns, ARRAY_SIZE(insns),
|
|
|
|
define_prefix, ifindex,
|
|
|
|
"have_v3_isa_extension",
|
|
|
|
"ISA extension v3",
|
|
|
|
"V3_ISA_EXTENSION");
|
|
|
|
}
|
|
|
|
|
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)
|
|
|
|
{
|
2022-05-23 23:04:19 +00:00
|
|
|
unsigned int prog_type = BPF_PROG_TYPE_UNSPEC;
|
|
|
|
const char *prog_type_str;
|
2020-02-26 16:59:35 +00:00
|
|
|
|
|
|
|
print_start_section("program_types",
|
|
|
|
"Scanning eBPF program types...",
|
|
|
|
"/*** eBPF program types ***/",
|
|
|
|
define_prefix);
|
|
|
|
|
2022-05-23 23:04:19 +00:00
|
|
|
while (true) {
|
|
|
|
prog_type++;
|
|
|
|
prog_type_str = libbpf_bpf_prog_type_str(prog_type);
|
|
|
|
/* libbpf will return NULL for variants unknown to it. */
|
|
|
|
if (!prog_type_str)
|
|
|
|
break;
|
|
|
|
|
|
|
|
probe_prog_type(prog_type, prog_type_str, supported_types, define_prefix,
|
|
|
|
ifindex);
|
|
|
|
}
|
2020-02-26 16:59:35 +00:00
|
|
|
|
|
|
|
print_end_section();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void section_map_types(const char *define_prefix, __u32 ifindex)
|
|
|
|
{
|
2022-05-23 23:04:22 +00:00
|
|
|
unsigned int map_type = BPF_MAP_TYPE_UNSPEC;
|
|
|
|
const char *map_type_str;
|
2020-02-26 16:59:35 +00:00
|
|
|
|
|
|
|
print_start_section("map_types",
|
|
|
|
"Scanning eBPF map types...",
|
|
|
|
"/*** eBPF map types ***/",
|
|
|
|
define_prefix);
|
|
|
|
|
2022-05-23 23:04:22 +00:00
|
|
|
while (true) {
|
|
|
|
map_type++;
|
|
|
|
map_type_str = libbpf_bpf_map_type_str(map_type);
|
|
|
|
/* libbpf will return NULL for variants unknown to it. */
|
|
|
|
if (!map_type_str)
|
|
|
|
break;
|
|
|
|
|
|
|
|
probe_map_type(map_type, map_type_str, define_prefix, ifindex);
|
|
|
|
}
|
2020-02-26 16:59:35 +00:00
|
|
|
|
|
|
|
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
|
|
|
{
|
2022-05-23 23:04:19 +00:00
|
|
|
unsigned int prog_type = BPF_PROG_TYPE_UNSPEC;
|
|
|
|
const char *prog_type_str;
|
2020-02-26 16:59:35 +00:00
|
|
|
|
|
|
|
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);
|
2022-05-23 23:04:19 +00:00
|
|
|
while (true) {
|
|
|
|
prog_type++;
|
|
|
|
prog_type_str = libbpf_bpf_prog_type_str(prog_type);
|
|
|
|
/* libbpf will return NULL for variants unknown to it. */
|
|
|
|
if (!prog_type_str)
|
|
|
|
break;
|
|
|
|
|
|
|
|
probe_helpers_for_progtype(prog_type, prog_type_str,
|
|
|
|
supported_types[prog_type],
|
|
|
|
define_prefix,
|
2020-04-29 14:45:04 +00:00
|
|
|
ifindex);
|
2022-05-23 23:04:19 +00:00
|
|
|
}
|
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);
|
2022-01-04 17:59:57 +00:00
|
|
|
probe_bounded_loops(define_prefix, ifindex);
|
bpftool: Probe for instruction set extensions
This patch introduces new probes to check whether the kernel supports
instruction set extensions v2 and v3. The first introduced eBPF
instructions BPF_J{LT,LE,SLT,SLE} in commit 92b31a9af73b ("bpf: add
BPF_J{LT,LE,SLT,SLE} instructions"). The second introduces 32-bit
variants of all jump instructions in commit 092ed0968bb6 ("bpf:
verifier support JMP32").
These probes are useful for userspace BPF projects that want to use newer
instruction set extensions on newer kernels, to reduce the programs'
sizes or their complexity. LLVM already provides an mcpu=probe option to
automatically probe the kernel and select the newest-supported
instruction set extension. That is however not flexible enough for all
use cases. For example, in Cilium, we only want to use the v3
instruction set extension on v5.10+, even though it is supported on all
kernels v5.1+.
Signed-off-by: Paul Chaignon <paul@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Quentin Monnet <quentin@isovalent.com>
Link: https://lore.kernel.org/bpf/3bfedcd9898c1f41ac67ca61f144fec84c6c3a92.1641314075.git.paul@isovalent.com
2022-01-04 18:00:13 +00:00
|
|
|
probe_v2_isa_extension(define_prefix, ifindex);
|
|
|
|
probe_v3_isa_extension(define_prefix, ifindex);
|
2020-02-26 16:59:35 +00:00
|
|
|
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.
|
2022-08-12 15:37:25 +00:00
|
|
|
* We do not use libcap so let's approximate, and restrict usage to
|
2020-04-29 14:45:06 +00:00
|
|
|
* 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
|
|
|
|
Revert "bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK"
This reverts commit a777e18f1bcd32528ff5dfd10a6629b655b05eb8.
In commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of
RLIMIT_MEMLOCK"), we removed the rlimit bump in bpftool, because the
kernel has switched to memcg-based memory accounting. Thanks to the
LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK, we attempted to keep compatibility
with other systems and ask libbpf to raise the limit for us if
necessary.
How do we know if memcg-based accounting is supported? There is a probe
in libbpf to check this. But this probe currently relies on the
availability of a given BPF helper, bpf_ktime_get_coarse_ns(), which
landed in the same kernel version as the memory accounting change. This
works in the generic case, but it may fail, for example, if the helper
function has been backported to an older kernel. This has been observed
for Google Cloud's Container-Optimized OS (COS), where the helper is
available but rlimit is still in use. The probe succeeds, the rlimit is
not raised, and probing features with bpftool, for example, fails.
A patch was submitted [0] to update this probe in libbpf, based on what
the cilium/ebpf Go library does [1]. It would lower the soft rlimit to
0, attempt to load a BPF object, and reset the rlimit. But it may induce
some hard-to-debug flakiness if another process starts, or the current
application is killed, while the rlimit is reduced, and the approach was
discarded.
As a workaround to ensure that the rlimit bump does not depend on the
availability of a given helper, we restore the unconditional rlimit bump
in bpftool for now.
[0] https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@isovalent.com/
[1] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Yafang Shao <laoar.shao@gmail.com>
Cc: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/bpf/20220610112648.29695-2-quentin@isovalent.com
2022-06-10 11:26:47 +00:00
|
|
|
set_max_rlimit();
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
bpftool: Add feature list (prog/map/link/attach types, helpers)
Add a "bpftool feature list" subcommand to list BPF "features".
Contrarily to "bpftool feature probe", this is not about the features
available on the system. Instead, it lists all features known to bpftool
from compilation time; in other words, all program, map, attach, link
types known to the libbpf version in use, and all helpers found in the
UAPI BPF header.
The first use case for this feature is bash completion: running the
command provides a list of types that can be used to produce the list of
candidate map types, for example.
Now that bpftool uses "standard" names provided by libbpf for the
program, map, link, and attach types, having the ability to list these
types and helpers could also be useful in scripts to loop over existing
items.
Sample output:
# bpftool feature list prog_types | grep -vw unspec | head -n 6
socket_filter
kprobe
sched_cls
sched_act
tracepoint
xdp
# bpftool -p feature list map_types | jq '.[1]'
"hash"
# bpftool feature list attach_types | grep '^cgroup_'
cgroup_inet_ingress
cgroup_inet_egress
[...]
cgroup_inet_sock_release
# bpftool feature list helpers | grep -vw bpf_unspec | wc -l
207
The "unspec" types and helpers are not filtered out by bpftool, so as to
remain closer to the enums, and to preserve the indices in the JSON
arrays (e.g. "hash" at index 1 == BPF_MAP_TYPE_HASH in map types list).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Müller <deso@posteo.net>
Link: https://lore.kernel.org/bpf/20220629203637.138944-2-quentin@isovalent.com
2022-06-29 20:36:36 +00:00
|
|
|
static const char *get_helper_name(unsigned int id)
|
|
|
|
{
|
|
|
|
if (id >= ARRAY_SIZE(helper_name))
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return helper_name[id];
|
|
|
|
}
|
|
|
|
|
2022-07-01 09:38:05 +00:00
|
|
|
static int do_list_builtins(int argc, char **argv)
|
bpftool: Add feature list (prog/map/link/attach types, helpers)
Add a "bpftool feature list" subcommand to list BPF "features".
Contrarily to "bpftool feature probe", this is not about the features
available on the system. Instead, it lists all features known to bpftool
from compilation time; in other words, all program, map, attach, link
types known to the libbpf version in use, and all helpers found in the
UAPI BPF header.
The first use case for this feature is bash completion: running the
command provides a list of types that can be used to produce the list of
candidate map types, for example.
Now that bpftool uses "standard" names provided by libbpf for the
program, map, link, and attach types, having the ability to list these
types and helpers could also be useful in scripts to loop over existing
items.
Sample output:
# bpftool feature list prog_types | grep -vw unspec | head -n 6
socket_filter
kprobe
sched_cls
sched_act
tracepoint
xdp
# bpftool -p feature list map_types | jq '.[1]'
"hash"
# bpftool feature list attach_types | grep '^cgroup_'
cgroup_inet_ingress
cgroup_inet_egress
[...]
cgroup_inet_sock_release
# bpftool feature list helpers | grep -vw bpf_unspec | wc -l
207
The "unspec" types and helpers are not filtered out by bpftool, so as to
remain closer to the enums, and to preserve the indices in the JSON
arrays (e.g. "hash" at index 1 == BPF_MAP_TYPE_HASH in map types list).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Müller <deso@posteo.net>
Link: https://lore.kernel.org/bpf/20220629203637.138944-2-quentin@isovalent.com
2022-06-29 20:36:36 +00:00
|
|
|
{
|
|
|
|
const char *(*get_name)(unsigned int id);
|
|
|
|
unsigned int id = 0;
|
|
|
|
|
|
|
|
if (argc < 1)
|
|
|
|
usage();
|
|
|
|
|
|
|
|
if (is_prefix(*argv, "prog_types")) {
|
|
|
|
get_name = (const char *(*)(unsigned int))libbpf_bpf_prog_type_str;
|
|
|
|
} else if (is_prefix(*argv, "map_types")) {
|
|
|
|
get_name = (const char *(*)(unsigned int))libbpf_bpf_map_type_str;
|
|
|
|
} else if (is_prefix(*argv, "attach_types")) {
|
|
|
|
get_name = (const char *(*)(unsigned int))libbpf_bpf_attach_type_str;
|
|
|
|
} else if (is_prefix(*argv, "link_types")) {
|
|
|
|
get_name = (const char *(*)(unsigned int))libbpf_bpf_link_type_str;
|
|
|
|
} else if (is_prefix(*argv, "helpers")) {
|
|
|
|
get_name = get_helper_name;
|
|
|
|
} else {
|
|
|
|
p_err("expected 'prog_types', 'map_types', 'attach_types', 'link_types' or 'helpers', got: %s", *argv);
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_start_array(json_wtr); /* root array */
|
|
|
|
|
|
|
|
while (true) {
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
name = get_name(id++);
|
|
|
|
if (!name)
|
|
|
|
break;
|
|
|
|
if (json_output)
|
|
|
|
jsonw_string(json_wtr, name);
|
|
|
|
else
|
|
|
|
printf("%s\n", name);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (json_output)
|
|
|
|
jsonw_end_array(json_wtr); /* root array */
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-17 15:27:50 +00:00
|
|
|
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"
|
2022-07-01 09:38:05 +00:00
|
|
|
" %1$s %2$s list_builtins GROUP\n"
|
2020-05-23 01:07:51 +00:00
|
|
|
" %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"
|
bpftool: Add feature list (prog/map/link/attach types, helpers)
Add a "bpftool feature list" subcommand to list BPF "features".
Contrarily to "bpftool feature probe", this is not about the features
available on the system. Instead, it lists all features known to bpftool
from compilation time; in other words, all program, map, attach, link
types known to the libbpf version in use, and all helpers found in the
UAPI BPF header.
The first use case for this feature is bash completion: running the
command provides a list of types that can be used to produce the list of
candidate map types, for example.
Now that bpftool uses "standard" names provided by libbpf for the
program, map, link, and attach types, having the ability to list these
types and helpers could also be useful in scripts to loop over existing
items.
Sample output:
# bpftool feature list prog_types | grep -vw unspec | head -n 6
socket_filter
kprobe
sched_cls
sched_act
tracepoint
xdp
# bpftool -p feature list map_types | jq '.[1]'
"hash"
# bpftool feature list attach_types | grep '^cgroup_'
cgroup_inet_ingress
cgroup_inet_egress
[...]
cgroup_inet_sock_release
# bpftool feature list helpers | grep -vw bpf_unspec | wc -l
207
The "unspec" types and helpers are not filtered out by bpftool, so as to
remain closer to the enums, and to preserve the indices in the JSON
arrays (e.g. "hash" at index 1 == BPF_MAP_TYPE_HASH in map types list).
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Daniel Müller <deso@posteo.net>
Link: https://lore.kernel.org/bpf/20220629203637.138944-2-quentin@isovalent.com
2022-06-29 20:36:36 +00:00
|
|
|
" GROUP := { prog_types | map_types | attach_types | link_types | helpers }\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[] = {
|
2022-07-01 09:38:05 +00:00
|
|
|
{ "probe", do_probe },
|
|
|
|
{ "list_builtins", do_list_builtins },
|
|
|
|
{ "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);
|
|
|
|
}
|