- 16 Aug, 2022 1 commit
-
-
Artem Savkov authored
Use SYS_PREFIX macro from bpf_misc.h instead of hard-coded '__x64_' prefix for sys_setdomainname attach point in lsm test. Signed-off-by:
Artem Savkov <asavkov@redhat.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220816055231.717006-1-asavkov@redhat.com
-
- 15 Aug, 2022 7 commits
-
-
Hangbin Liu authored
Similar with commit 10b62d6a ("libbpf: Add names for auxiliary maps"), let's make bpf_prog_load() also ignore name if kernel doesn't support program name. To achieve this, we need to call sys_bpf_prog_load() directly in probe_kern_prog_name() to avoid circular dependency. sys_bpf_prog_load() also need to be exported in the libbpf_internal.h file. Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Signed-off-by:
Quentin Monnet <quentin@isovalent.com> Link: https://lore.kernel.org/bpf/20220813000936.6464-1-liuhangbin@gmail.com
-
Daniel Xu authored
The previous selftest changes require two kconfig changes in bpf-ci. Signed-off-by:
Daniel Xu <dxu@dxuuu.xyz> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/bpf/2c27c6ebf7a03954915f83560653752450389564.1660254747.git.dxu@dxuuu.xyz
-
Daniel Xu authored
Test that the prog can read from the connection mark. This test is nice because it ensures progs can interact with netfilter subsystem correctly. Signed-off-by:
-
Daniel Xu authored
Add a test where we do a conntrack lookup on an existing connection. This is nice because it's a more realistic test than artifically creating a ct entry and looking it up afterwards. Signed-off-by:
-
Quentin Monnet authored
When bpftool is linked against libcap, the library runs a "constructor" function to compute the number of capabilities of the running kernel [0], at the beginning of the execution of the program. As part of this, it performs multiple calls to prctl(). Some of these may fail, and set errno to a non-zero value: # strace -e prctl ./bpftool version prctl(PR_CAPBSET_READ, CAP_MAC_OVERRIDE) = 1 prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument) ** fprintf added at the top of main(): we have errno == 1 ./bpftool v7.0.0 using libbpf v1.0 features: libbfd, libbpf_strict, skeletons +++ exited with 0 +++ This has been addressed in libcap 2.63 [1], but until this version is available everywhere, we can fix it on bpftool side. Let's clean errno at the beginning of the main() function, to make sure that these checks do not interfere with the batch mode, where we error out if errno is set after a bpftool command. [0] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/tree/libcap/cap_alloc.c?h=libcap-2.65#n20 [1] https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=f25a1b7e69f7b33e6afb58b3e38f3450b7d2d9a0Signed-off-by: -
Quentin Monnet authored
Adding or removing room space _below_ layers 2 or 3, as the description mentions, is ambiguous. This was written with a mental image of the packet with layer 2 at the top, layer 3 under it, and so on. But it has led users to believe that it was on lower layers (before the beginning of the L2 and L3 headers respectively). Let's make it more explicit, and specify between which layers the room space is adjusted. Reported-by:
Rumen Telbizov <rumen.telbizov@menlosecurity.com> Signed-off-by:
-
Quentin Monnet authored
This is the wrong library name: libcap, not libpcap. Signed-off-by:
-
- 11 Aug, 2022 1 commit
-
-
Hangbin Liu authored
The bpftool self-created maps can appear in final map show output due to deferred removal in kernel. These maps don't have a name, which would make users confused about where it comes from. With a libbpf_ prefix name, users could know who created these maps. It also could make some tests (like test_offload.py, which skip base maps without names as a workaround) filter them out. Kernel adds bpf prog/map name support in the same merge commit fadad670 ("Merge branch 'bpf-extend-info'"). So we can also use kernel_supports(NULL, FEAT_PROG_NAME) to check if kernel supports map name. As discussed [1], Let's make bpf_map_create accept non-null name string, and silently ignore the name if kernel doesn't support. [1] https://lore.kernel.org/bpf/CAEf4BzYL1TQwo1231s83pjTdFPk9XWWhfZC5=KzkU-VO0k=0Ug@mail.gmail.com/Signed-off-by:
-
- 10 Aug, 2022 12 commits
-
-
Yafang Shao authored
Let's use the generic helper bpf_map_area_alloc() instead of the open-coded kzalloc helpers in bpf maps creation path. Signed-off-by:
Yafang Shao <laoar.shao@gmail.com> Link: https://lore.kernel.org/r/20220810151840.16394-5-laoar.shao@gmail.comSigned-off-by:
Alexei Starovoitov <ast@kernel.org>
-
Yafang Shao authored
Some of the bpf maps are created with __GFP_NOWARN, i.e. arraymap, bloom_filter, bpf_local_storage, bpf_struct_ops, lpm_trie, queue_stack_maps, reuseport_array, stackmap and xskmap, while others are created without __GFP_NOWARN, i.e. cpumap, devmap, hashtab, local_storage, offload, ringbuf and sock_map. But there are not key differences between the creation of these maps. So let make this allocation flag consistent in all bpf maps creation. Then we can use a generic helper to alloc all bpf maps. Signed-off-by:
-
Yafang Shao authored
bpf_map_area_alloc() should be paired with bpf_map_area_free(). Signed-off-by:
-
Yafang Shao authored
__GFP_ZERO will clear the memory, so we don't need to memset it. Signed-off-by:
-
Andrii Nakryiko authored
As suggested in [0], make sure that libbpf_print saves and restored errno and as such guaranteed that no matter what actual print callback user installs, macros like pr_warn/pr_info/pr_debug are completely transparent as far as errno goes. While libbpf code is pretty careful about not clobbering important errno values accidentally with pr_warn(), it's a trivial change to make sure that pr_warn can be used anywhere without a risk of clobbering errno. No functional changes, just future proofing. [0] https://github.com/libbpf/libbpf/pull/536Signed-off-by:
Daniel Müller <deso@posteo.net> Link: https://lore.kernel.org/r/20220810183425.1998735-1-andrii@kernel.orgSigned-off-by:
-
Alexei Starovoitov authored
Artem Savkov says: ==================== eBPF is often used for kernel debugging, and one of the widely used and powerful debugging techniques is post-mortem debugging with a full memory dump. Triggering a panic at exactly the right moment allows the user to get such a dump and thus a better view at the system's state. Right now the only way to do this in BPF is to signal userspace to trigger kexec/panic. This is suboptimal as going through userspace requires context changes and adds significant delays taking system further away from "the right moment". On a single-cpu system the situation is even worse because BPF program won't even be able to block the thread of interest. This patchset tries to solve this problem by allowing properly marked tracing bpf programs to call crash_kexec() kernel function. The only requirement for now to run programs calling crash_kexec() or other destructive kfuncs is CAP_SYS_BOOT capability. When signature checking for bpf programs is available it is possible that stricter rules will be applied to programs utilizing destructive kfuncs. Changes in v5: - documentation numbering fixed - no more warning on failed kfunc registration Changes in v4: - added description for KF_DESTRUCTIVE flag to documentation Changes in v3: - moved kfunc set registration to kernel/bpf/helpers.c Changes in v2: - BPF_PROG_LOAD flag dropped as it doesn't fully achieve it's aim of preventing accidental execution of destructive bpf programs - selftest moved to the end of patchset - switched to kfunc destructive flag instead of a separate set Changes from RFC: - sysctl knob dropped - using crash_kexec() instead of panic() - using kfuncs instead of adding a new helper ==================== Signed-off-by: -
Artem Savkov authored
Add a test checking that programs calling destructive kfuncs can only do so if they have CAP_SYS_BOOT capabilities. Signed-off-by:
-
Artem Savkov authored
Allow properly marked bpf programs to call crash_kexec(). Signed-off-by:
-
Artem Savkov authored
Add KF_DESTRUCTIVE flag for destructive functions. Functions with this flag set will require CAP_SYS_BOOT capabilities. Signed-off-by:
-
Shibin Koikkara Reeny authored
Poll test case was not testing all the functionality of the poll feature in the test suite. This patch updates the poll test case which contains 2 test cases to test the RX and the TX poll functionality and additional 2 more test cases to check the timeout feature of the poll event. Poll test suite has 4 test cases: 1. TEST_TYPE_RX_POLL: Check if RX path POLLIN function works as expect. TX path can use any method to send the traffic. 2. TEST_TYPE_TX_POLL: Check if TX path POLLOUT function works as expect. RX path can use any method to receive the traffic. 3. TEST_TYPE_POLL_RXQ_EMPTY: Call poll function with parameter POLLIN on empty RX queue will cause timeout. If timeout then test case passes. 4. TEST_TYPE_POLL_TXQ_FULL: When TX queue is filled and packets are not cleaned by the kernel then if we invoke the poll function with POLLOUT it should trigger timeout. Signed-off-by:
Shibin Koikkara Reeny <shibin.koikkara.reeny@intel.com> Signed-off-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://lore.kernel.org/bpf/20220803144354.98122-1-shibin.koikkara.reeny@intel.com
-
Joanne Koong authored
Add an additional test, "data_slice_use_after_release2", for ensuring that data slices are correctly invalidated by the verifier after the dynptr whose ref obj id they track is released. In particular, this tests data slice invalidation for dynptrs located at a non-zero offset from the frame pointer. Signed-off-by:
Joanne Koong <joannelkoong@gmail.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/r/20220809214055.4050604-2-joannelkoong@gmail.comSigned-off-by:
-
Joanne Koong authored
When a data slice is obtained from a dynptr (through the bpf_dynptr_data API), the ref obj id of the dynptr must be found and then associated with the data slice. The ref obj id of the dynptr must be found *before* the caller saved regs are reset. Without this fix, the ref obj id tracking is not correct for dynptrs that are at an offset from the frame pointer. Please also note that the data slice's ref obj id must be assigned after the ret types are parsed, since RET_PTR_TO_ALLOC_MEM-type return regs get zero-marked. Fixes: 34d4ef57 ("bpf: Add dynptr data slices") Signed-off-by:
David Vernet <void@manifault.com> Link: https://lore.kernel.org/r/20220809214055.4050604-1-joannelkoong@gmail.comSigned-off-by:
-
- 09 Aug, 2022 11 commits
-
-
Daniel Xu authored
Before, you could see the following errors: $ ./vmtest.sh -j ./vmtest.sh: option requires an argument -- j ./vmtest.sh: line 357: OPTARG: unbound variable $ ./vmtest.sh -z ./vmtest.sh: illegal option -- z ./vmtest.sh: line 357: OPTARG: unbound variable Fix by adding ':' as first character of optstring. Reason is that getopts requires ':' as the first character for OPTARG to be set in the `?` and `:` error cases. Note that the ':' as the first character of the optstring switches getopts to silent mode. The desire to run in this mode seems to have been there all along, as the script takes care of reporting errors. Signed-off-by:
-
Daniel Xu authored
Set the exit trap only after argument parsing is done. This way argument parse failure or `-h` will not require sudo. Reasoning is that it's confusing that a help message would require root access. Signed-off-by:
-
Yonghong Song authored
Currently in funciton __get_type_size(), the corresponding btf_type is returned only in invalid cases. Let us always return btf_type regardless of valid or invalid cases. Such a new functionality will be used in subsequent patches. Signed-off-by:
Yonghong Song <yhs@fb.com> Link: https://lore.kernel.org/r/20220807175116.4179242-1-yhs@fb.comSigned-off-by:
-
Alexei Starovoitov authored
Kurt Kanzenbach says: ==================== Hi, add a BPF-helper for accessing CLOCK_TAI. Use cases for such a BPF helper include functionalities such as Tx launch time (e.g. ETF and TAPRIO Qdiscs), timestamping and policing. Patch #1 - Introduce BPF helper Patch #2 - Add test case (skb based) Changes since v1: * Update changelog (Alexei Starovoitov) * Add test case (Alexei Starovoitov, Andrii Nakryiko) * Add missing function prototype (netdev ci) Previous versions: * v1: https://lore.kernel.org/r/20220606103734.92423-1-kurt@linutronix.de/ Jesper Dangaard Brouer (1): bpf: Add BPF-helper for accessing CLOCK_TAI ==================== Signed-off-by:
-
Kurt Kanzenbach authored
Add BPF-helper test case for CLOCK_TAI access. The added test verifies that: * Timestamps are generated * Timestamps are moving forward * Timestamps are reasonable Signed-off-by:
Kurt Kanzenbach <kurt@linutronix.de> Link: https://lore.kernel.org/r/20220809060803.5773-3-kurt@linutronix.deSigned-off-by:
-
Jesper Dangaard Brouer authored
Commit 3dc6ffae ("timekeeping: Introduce fast accessor to clock tai") introduced a fast and NMI-safe accessor for CLOCK_TAI. Especially in time sensitive networks (TSN), where all nodes are synchronized by Precision Time Protocol (PTP), it's helpful to have the possibility to generate timestamps based on CLOCK_TAI instead of CLOCK_MONOTONIC. With a BPF helper for TAI in place, it becomes very convenient to correlate activity across different machines in the network. Use cases for such a BPF helper include functionalities such as Tx launch time (e.g. ETF and TAPRIO Qdiscs) and timestamping. Note: CLOCK_TAI is nothing new per se, only the NMI-safe variant of it is. Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> [Kurt: Wrote changelog and renamed helper] Signed-off-by:
-
Dave Marchevsky authored
Discussion around a recently-submitted patch provided historical context for check_refcount_ok [0]. Specifically, the function and its helpers - may_be_acquire_function and arg_type_may_be_refcounted - predate the OBJ_RELEASE type flag and the addition of many more helpers with acquire/release semantics. The purpose of check_refcount_ok is to ensure: 1) Helper doesn't have multiple uses of return reg's ref_obj_id 2) Helper with release semantics only has one arg needing to be released, since that's tracked using meta->ref_obj_id With current verifier, it's safe to remove check_refcount_ok and its helpers. Since addition of OBJ_RELEASE type flag, case 2) has been handled by the arg_type_is_release check in check_func_arg. To ensure case 1) won't result in verifier silently prioritizing one use of ref_obj_id, this patch adds a helper_multiple_ref_obj_use check which fails loudly if a helper passes > 1 test for use of ref_obj_id. [0]: lore.kernel.org/bpf/20220713234529.4154673-1-davemarchevsky@fb.com Signed-off-by:
Dave Marchevsky <davemarchevsky@fb.com> Acked-by:
-
Kumar Kartikeya Dwivedi authored
The current ifdefry for code shared by the BPF and ctnetlink side looks ugly. As per Pablo's request, simplify this by unconditionally compiling in the code. This can be revisited when the shared code between the two grows further. Suggested-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Hao Luo authored
In bpf_seq_read, seq->op->next() could return an ERR and jump to the label stop. However, the existing code in stop does not handle the case when p (returned from next()) is an ERR. Adds the handling of ERR of p by converting p into an error and jumping to done. Because all the current implementations do not have a case that returns ERR from next(), so this patch doesn't have behavior changes right now. Acked-by:
Hao Luo <haoluo@google.com> Link: https://lore.kernel.org/r/20220805214821.1058337-4-haoluo@google.comSigned-off-by:
-
Yosry Ahmed authored
cgroup_get_from_file() currently fails with -EBADF if called on cgroup v1. However, the current implementation works on cgroup v1 as well, so the restriction is unnecessary. This enabled cgroup_get_from_fd() to work on cgroup v1, which would be the only thing stopping bpf cgroup_iter from supporting cgroup v1. Signed-off-by:
Yosry Ahmed <yosryahmed@google.com> Acked-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Benjamin Tissoires authored
This allows to declare a kfunc as sleepable and prevents its use in a non sleepable program. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Co-developed-by:
-
- 08 Aug, 2022 5 commits
-
-
Dave Marchevsky authored
Most tools which use bpf_get_stack or bpf_get_stackid symbolicate the stack - meaning the stack of addresses in the target process' address space is transformed into meaningful symbol names. The BPF_F_USER_BUILD_ID flag eases this process by finding the build_id of the file-backed vma which the address falls in and translating the address to an offset within the backing file. To be more specific, the offset is a "file offset" from the beginning of the backing file. The symbols in ET_DYN ELF objects have a st_value which is also described as an "offset" - but an offset in the process address space, relative to the base address of the object. It's necessary to translate between the "file offset" and "virtual address offset" during symbolication before they can be directly compared. Failure to do so can lead to confusing bugs, so this patch clarifies language in the documentation in an attempt to keep this from happening. Signed-off-by:
-
Hengqi Chen authored
Currently, resolve_full_path() requires executable permission for both programs and shared libraries. This causes failures on distos like Debian since the shared libraries are not installed executable and Linux is not requiring shared libraries to have executable permissions. Let's remove executable permission check for shared libraries. Reported-by:
Goro Fuji <goro@fastly.com> Signed-off-by:
Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by:
-
Joanne Koong authored
This patch cleans up a few things in the verifier: * type_is_pkt_pointer(): Future work (skb + xdp dynptrs [0]) will be using the reg type PTR_TO_PACKET | PTR_MAYBE_NULL. type_is_pkt_pointer() should return true for any type whose base type is PTR_TO_PACKET, regardless of flags attached to it. * reg_type_may_be_refcounted_or_null(): Get the base type at the start of the function to avoid having to recompute it / improve readability * check_func_proto(): remove unnecessary 'meta' arg * check_helper_call(): Use switch casing on the base type of return value instead of nested ifs on the full type There are no functional behavior changes. [0] https://lore.kernel.org/bpf/20220726184706.954822-1-joannelkoong@gmail.com/Signed-off-by:Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20220802214638.3643235-1-joannelkoong@gmail.com
-
Andrii Nakryiko authored
Add explicit error message if BPF object file is still using legacy BPF map definitions in SEC("maps"). Before this change, if BPF object file is still using legacy map definition user will see a bit confusing: libbpf: elf: skipping unrecognized data section(4) maps libbpf: prog 'handler': bad map relo against 'server_map' in section 'maps' Now libbpf will be explicit about rejecting "maps" ELF section: libbpf: elf: legacy map definitions in 'maps' section are not supported by libbpf v1.0+ Signed-off-by: -
Joanne Koong authored
This patch cleans up a few things: * dynptr_fail.c: There is no sys_nanosleep tracepoint. dynptr_fail only tests that the prog load fails, so just SEC("?raw_tp") suffices here. * test_bpf_cookie: There is no sys_nanosleep kprobe. The prog is loaded in userspace through bpf_program__attach_kprobe_opts passing in SYS_NANOSLEEP_KPROBE_NAME, so just SEC("k{ret}probe") suffices here. * test_helper_restricted: There is no sys_nanosleep kprobe. test_helper_restricted only tests that the prog load fails, so just SEC("?kprobe")( suffices here. There are no functional changes. Suggested-by:
-
- 04 Aug, 2022 3 commits
-
-
James Hilliard authored
GCC expects the always_inline attribute to only be set on inline functions, as such we should make all functions with this attribute use the __always_inline macro which makes the function inline and sets the attribute. Fixes errors like: /home/buildroot/bpf-next/tools/testing/selftests/bpf/tools/include/bpf/bpf_tracing.h:439:1: error: ‘always_inline’ function might not be inlinable [-Werror=attributes] 439 | ____##name(unsigned long long *ctx, ##args) | ^~~~ Signed-off-by:James Hilliard <james.hilliard1@gmail.com> Signed-off-by:
-
Manu Bretelle authored
bpftool was limiting the length of names to BPF_OBJ_NAME_LEN in prog_parse fds. Since commit b662000a ("bpftool: Adding support for BTF program names") we can get the full program name from BTF. This patch removes the restriction of name length when running `bpftool prog show name ${name}`. Test: Tested against some internal program names that were longer than `BPF_OBJ_NAME_LEN`, here a redacted example of what was ran to test. # previous behaviour $ sudo bpftool prog show name some_long_program_name Error: can't parse name # with the patch $ sudo ./bpftool prog show name some_long_program_name 123456789: tracing name some_long_program_name tag taghexa gpl .... ... ... ... # too long sudo ./bpftool prog show name $(python3 -c 'print("A"*128)') Error: can't parse name # not too long but no match $ sudo ./bpftool prog show name $(python3 -c 'print("A"*127)') Signed-off-by:
Manu Bretelle <chantr4@gmail.com> Signed-off-by:
-
Florian Fainelli authored
GCC-11 warns about the possibly unitialized err variable in probe_map_create: libbpf_probes.c: In function 'probe_map_create': libbpf_probes.c:361:38: error: 'err' may be used uninitialized in this function [-Werror=maybe-uninitialized] 361 | return fd < 0 && err == exp_err ? 1 : 0; | ~~~~^~~~~~~~~~ Fixes: 878d8def ("libbpf: Rework feature-probing APIs") Signed-off-by:Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
