summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/bpf
AgeCommit message (Collapse)AuthorFilesLines
2025-07-02selftests/bpf: Negative test case for ref_obj_id in argsPaul Chaignon1-0/+24
This patch adds a test case, as shown below, for the verifier error "more than one arg with ref_obj_id". 0: (b7) r2 = 20 1: (b7) r3 = 0 2: (18) r1 = 0xffff92cee3cbc600 4: (85) call bpf_ringbuf_reserve#131 5: (55) if r0 == 0x0 goto pc+3 6: (bf) r1 = r0 7: (bf) r2 = r0 8: (85) call bpf_tcp_raw_gen_syncookie_ipv4#204 9: (95) exit This error is currently incorrectly reported as a verifier bug, with a warning. The next patch in this series will address that. Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/3ba78e6cda47ccafd6ea70dadbc718d020154664.1751463262.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2025-07-02selftests/bpf: null checks for rdonly_untrusted_mem should be preservedEduard Zingerman1-0/+21
Test case checking that verifier does not assume rdonly_untrusted_mem values as not null. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250702073620.897517-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
2025-07-02selftests/bpf: Don't call fsopen() as privileged userMatteo Croce1-20/+21
In the BPF token example, the fsopen() syscall is called as privileged user. This is unneeded because fsopen() can be called also as unprivileged user from the user namespace. As the `fs_fd` file descriptor which was sent back and forth is still the same, keep it open instead of cloning and closing it twice via SCM_RIGHTS. cfr. https://github.com/systemd/systemd/pull/36134 Signed-off-by: Matteo Croce <teknoraver@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Christian Brauner <brauner@kernel.org> Link: https://lore.kernel.org/bpf/20250701183123.31781-1-technoboy85@gmail.com
2025-07-02selftests/bpf: Add tests for bpf_cgroup_read_xattrSong Liu4-0/+366
Add tests for different scenarios with bpf_cgroup_read_xattr: 1. Read cgroup xattr from bpf_cgroup_from_id; 2. Read cgroup xattr from bpf_cgroup_ancestor; 3. Read cgroup xattr from css_iter; 4. Use bpf_cgroup_read_xattr in LSM hook security_socket_connect. 5. Use bpf_cgroup_read_xattr in cgroup program. Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/20250623063854.1896364-5-song@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-07-02selftests/bpf: Add negative test cases for snprintfPaul Chaignon1-0/+2
This patch adds a couple negative test cases with a trailing % at the end of the format string. The %p% case was fixed by the previous commit, whereas the %s% case was already successfully rejected before. Acked-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/0669bf6eb4f9e5bb10e949d60311c06e2d942447.1751395489.git.paul.chaignon@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-07-01selftests/bpf: Fix spelling mistake "subtration" -> "subtraction"Colin Ian King1-2/+2
There are spelling mistakes in description text. Fix these. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250630125528.563077-1-colin.i.king@gmail.com
2025-07-01selftests/bpf: Enable dynptr/test_probe_read_user_str_dynptrMykyta Yatsenko1-1/+0
Enable previously disabled dynptr/test_probe_read_user_str_dynptr test, after the fix it depended on was merged into bpf-next. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250630133515.1108325-1-mykyta.yatsenko5@gmail.com
2025-06-28selftests/bpf: bpf_rdonly_cast u{8,16,32,64} access testsEduard Zingerman1-0/+41
Tests with aligned and misaligned memory access of different sizes via pointer returned by bpf_rdonly_cast(). Suggested-by: Andrii Nakryiko <andrii.nakryiko@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250627015539.1439656-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-28selftests/bpf: improve error messages in veristatMykyta Yatsenko1-11/+25
Return error if preset parsing fails. Avoid proceeding with veristat run if preset does not parse. Before: ``` ./veristat set_global_vars.bpf.o -G "arr[999999999999999999999] = 1" Failed to parse value '999999999999999999999' Processing 'set_global_vars.bpf.o'... File Program Verdict Duration (us) Insns States Program size Jited size --------------------- ---------------- ------- ------------- ----- ------ ------------ ---------- set_global_vars.bpf.o test_set_globals success 27 64 0 82 0 --------------------- ---------------- ------- ------------- ----- ------ ------------ ---------- Done. Processed 1 files, 0 programs. Skipped 1 files, 0 programs. ``` After: ``` ./veristat set_global_vars.bpf.o -G "arr[999999999999999999999] = 1" Failed to parse value '999999999999999999999' Failed to parse global variable presets: arr[999999999999999999999] = 1 ``` Improve error messages: * If preset struct member can't be found. * Array index out of bounds Extract rtrim function. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250627144342.686896-1-mykyta.yatsenko5@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-28selftests/bpf: Fix cgroup_xattr/read_cgroupfs_xattrSong Liu4-97/+49
cgroup_xattr/read_cgroupfs_xattr has two issues: 1. cgroup_xattr/read_cgroupfs_xattr messes up lo without creating a netns first. This causes issue with other tests. Fix this by using a different hook (lsm.s/file_open) and not messing with lo. 2. cgroup_xattr/read_cgroupfs_xattr sets up cgroups without proper mount namespaces. Fix this by using the existing cgroup helpers. A new helper set_cgroup_xattr() is added to set xattr on cgroup files. Fixes: f4fba2d6d282 ("selftests/bpf: Add tests for bpf_cgroup_read_xattr") Reported-by: Alexei Starovoitov <ast@kernel.org> Closes: https://lore.kernel.org/bpf/CAADnVQ+iqMi2HEj_iH7hsx+XJAsqaMWqSDe4tzcGAnehFWA9Sw@mail.gmail.com/ Signed-off-by: Song Liu <song@kernel.org> Tested-by: Eduard Zingerman <eddyz87@gmail.com> Tested-by: Ihor Solodrai <ihor.solodrai@linux.dev> Link: https://lore.kernel.org/r/20250627191221.765921-1-song@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-27Merge branch 'vfs-6.17.bpf' of ↵Alexei Starovoitov4-0/+366
https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs Merge branch 'vfs-6.17.bpf' from vfs tree into bpf-next/master and resolve conflicts. Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-27Merge tag 'for-netdev' of ↵Jakub Kicinski2-0/+95
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next Daniel Borkmann says: ==================== pull-request: bpf-next 2025-06-27 We've added 6 non-merge commits during the last 8 day(s) which contain a total of 6 files changed, 120 insertions(+), 20 deletions(-). The main changes are: 1) Fix RCU usage in task_cls_state() for BPF programs using helpers like bpf_get_cgroup_classid_curr() outside of networking, from Charalampos Mitrodimas. 2) Fix a sockmap race between map_update and a pending workqueue from an earlier map_delete freeing the old psock where both pointed to the same psock->sk, from Jiayuan Chen. 3) Fix a data corruption issue when using bpf_msg_pop_data() in kTLS which failed to recalculate the ciphertext length, also from Jiayuan Chen. 4) Remove xdp_redirect_map{,_err} trace events since they are unused and also hide XDP trace events under CONFIG_BPF_SYSCALL, from Steven Rostedt. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: xdp: tracing: Hide some xdp events under CONFIG_BPF_SYSCALL xdp: Remove unused events xdp_redirect_map and xdp_redirect_map_err net, bpf: Fix RCU usage in task_cls_state() for BPF programs selftests/bpf: Add test to cover ktls with bpf_msg_pop_data bpf, ktls: Fix data corruption when using bpf_msg_pop_data() in ktls bpf, sockmap: Fix psock incorrectly pointing to sk ==================== Link: https://patch.msgid.link/20250626230111.24772-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-06-26selftests/bpf: Test array presets in veristatMykyta Yatsenko2-24/+159
Modify existing veristat tests to verify that array presets are applied as expected. Introduce few negative tests as well to check that common error modes are handled. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20250625165904.87820-4-mykyta.yatsenko5@gmail.com
2025-06-26selftests/bpf: Support array presets in veristatMykyta Yatsenko1-50/+189
Implement support for presetting values for array elements in veristat. For example: ``` sudo ./veristat set_global_vars.bpf.o -G "arr[3] = 1" ``` Arrays of structures and structure of arrays work, but each individual scalar value has to be set separately: `foo[1].bar[2] = value`. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20250625165904.87820-3-mykyta.yatsenko5@gmail.com
2025-06-26selftests/bpf: Separate var preset parsing in veristatMykyta Yatsenko1-53/+99
Refactor var preset parsing in veristat to simplify implementation. Prepare parsed variable beforehand so that parsing logic is separated from functionality of calculating offsets and searching fields. Introduce rvalue struct, storing either int or enum (string value), will be reused in the next patch, extract parsing rvalue into a separate function. Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20250625165904.87820-2-mykyta.yatsenko5@gmail.com
2025-06-26Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf after rc3Alexei Starovoitov7-85/+112
Cross-merge BPF, perf and other fixes after downstream PRs. It restores BPF CI to green after critical fix commit bc4394e5e79c ("perf: Fix the throttle error of some clock events") No conflicts. Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26selftests/bpf: Add tests for string kfuncsViktor Malik4-0/+212
Add both positive and negative tests cases using string kfuncs added in the previous patches. Positive tests check that the functions work as expected. Negative tests pass various incorrect strings to the kfuncs and check for the expected error codes: -E2BIG when passing too long strings -EFAULT when trying to read inaccessible kernel memory -ERANGE when passing userspace pointers on arches with non-overlapping address spaces A majority of the tests use the RUN_TESTS helper which executes BPF programs with BPF_PROG_TEST_RUN and check for the expected return value. An exception to this are tests for long strings as we need to memset the long string from userspace (at least I haven't found an ergonomic way to memset it from a BPF program), which cannot be done using the RUN_TESTS infrastructure. Suggested-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/r/090451a2e60c9ae1dceb4d1bfafa3479db5c7481.1750917800.git.vmalik@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26selftests/bpf: Allow macros in __retvalViktor Malik3-23/+19
Allow macro expansion for values passed to the `__retval` and `__retval_unpriv` attributes. This is especially useful for testing programs which return various error codes. With this change, the code for parsing special literals can be made simpler, as the literals are defined via macros. The only exception is INT_MIN which expands to (-INT_MAX -1), which is not single number and cannot be parsed by strtol. So, we instead use a prefixed literal _INT_MIN in __retval and handle it separately (assign the expected return to INT_MIN). Also, strtol cannot handle the "ll" suffix so change the value of POINTER_VALUE from 0xcafe4all to 0xbadcafe. Signed-off-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/r/a6c6b551ae0575351faa7b7a1df52f9341a5cbe8.1750917800.git.vmalik@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26selftests/bpf: adapt one more case in test_lru_map to the new target_freeWillem de Bruijn1-15/+18
The below commit that updated BPF_MAP_TYPE_LRU_HASH free target, also updated tools/testing/selftests/bpf/test_lru_map to match. But that missed one case that passes with 4 cores, but fails at higher cpu counts. Update test_lru_sanity3 to also adjust its expectation of target_free. This time tested with 1, 4, 16, 64 and 384 cpu count. Fixes: d4adf1c9ee77 ("bpf: Adjust free target to avoid global starvation of LRU map") Signed-off-by: Willem de Bruijn <willemb@google.com> Link: https://lore.kernel.org/r/20250625210412.2732970-1-willemdebruijn.kernel@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26selftests/bpf: check operations on untrusted ro pointers to memEduard Zingerman2-0/+145
The following cases are tested: - it is ok to load memory at any offset from rdonly_untrusted_mem; - rdonly_untrusted_mem offset/bounds are not tracked; - writes into rdonly_untrusted_mem are forbidden; - atomic operations on rdonly_untrusted_mem are forbidden; - rdonly_untrusted_mem can't be passed as a memory argument of a helper of kfunc; - it is ok to use PTR_TO_MEM and PTR_TO_BTF_ID in a same load instruction. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250625182414.30659-4-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26selftests/bpf: Add tests for BPF_NEG range tracking logicSong Liu1-0/+70
BPF_REG now has range tracking logic. Add selftests for BPF_NEG. Specifically, return value of LSM hook lsm.s/socket_connect is used to show that the verifer tracks BPF_NEG(1) falls in the [-4095, 0] range; while BPF_NEG(100000) does not fall in that range. Signed-off-by: Song Liu <song@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250625164025.3310203-3-song@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-26bpf: Add range tracking for BPF_NEGSong Liu2-10/+23
Add range tracking for instruction BPF_NEG. Without this logic, a trivial program like the following will fail volatile bool found_value_b; SEC("lsm.s/socket_connect") int BPF_PROG(test_socket_connect) { if (!found_value_b) return -1; return 0; } with verifier log: "At program exit the register R0 has smin=0 smax=4294967295 should have been in [-4095, 0]". This is because range information is lost in BPF_NEG: 0: R1=ctx() R10=fp0 ; if (!found_value_b) @ xxxx.c:24 0: (18) r1 = 0xffa00000011e7048 ; R1_w=map_value(...) 2: (71) r0 = *(u8 *)(r1 +0) ; R0_w=scalar(smin32=0,smax=255) 3: (a4) w0 ^= 1 ; R0_w=scalar(smin32=0,smax=255) 4: (84) w0 = -w0 ; R0_w=scalar(range info lost) Note that, the log above is manually modified to highlight relevant bits. Fix this by maintaining proper range information with BPF_NEG, so that the verifier will know: 4: (84) w0 = -w0 ; R0_w=scalar(smin32=-255,smax=0) Also updated selftests based on the expected behavior. Signed-off-by: Song Liu <song@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250625164025.3310203-2-song@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-25selftests/bpf: Fix usdt multispec failure with arm64/clang20 selftest buildYonghong Song1-4/+10
When building the selftest with arm64/clang20, the following test failed: ... ubtest_multispec_usdt:PASS:usdt_100_called 0 nsec subtest_multispec_usdt:PASS:usdt_100_sum 0 nsec subtest_multispec_usdt:FAIL:usdt_300_bad_attach unexpected pointer: 0xaaaad82a2a80 #471/2 usdt/multispec:FAIL #471 usdt:FAIL But arm64/gcc11 built kernel selftests succeeded. Further debug found arm64/clang generated code has much less argument pattern after dedup, but gcc generated code has a lot more. Check usdt probes with usdt.test.o on arm64 platform: with gcc11 build binary: stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000054f8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp] stapsdt 0x00000031 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000005510, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 4] ... stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000005660, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 60] ... stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000070e8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 1192] stapsdt 0x00000034 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000007100, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 1196] ... stapsdt 0x00000032 NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000009ec4, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[sp, 60] with clang20 build binary: stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000009a0, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000009b8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] ... stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000002590, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x9] stapsdt 0x0000002e NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x00000000000025a8, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x8] ... stapsdt 0x0000002f NT_STAPSDT (SystemTap probe descriptors) Provider: test Name: usdt_300 Location: 0x0000000000007fdc, Base: 0x0000000000000000, Semaphore: 0x0000000000000008 Arguments: -4@[x10] There are total 300 locations for usdt_300. For gcc11 built binary, there are 300 spec's. But for clang20 built binary, there are 3 spec's. The default BPF_USDT_MAX_SPEC_CNT is 256, so bpf_program__attach_usdt() will fail for gcc but it will succeed with clang. To fix the problem, do not do bpf_program__attach_usdt() for usdt_300 with arm64/clang setup. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250624211802.2198821-1-yonghong.song@linux.dev
2025-06-25libbpf: Fix possible use-after-free for externsAdin Scannell1-0/+16
The `name` field in `obj->externs` points into the BTF data at initial open time. However, some functions may invalidate this after opening and before loading (e.g. `bpf_map__set_value_size`), which results in pointers into freed memory and undefined behavior. The simplest solution is to simply `strdup` these strings, similar to the `essent_name`, and free them at the same time. In order to test this path, the `global_map_resize` BPF selftest is modified slightly to ensure the presence of an extern, which causes this test to fail prior to the fix. Given there isn't an obvious API or error to test against, I opted to add this to the existing test as an aspect of the resizing feature rather than duplicate the test. Fixes: 9d0a23313b1a ("libbpf: Add capability for resizing datasec maps") Signed-off-by: Adin Scannell <amscanne@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250625050215.2777374-1-amscanne@meta.com
2025-06-25selftests/bpf: Add testcases for BPF_ADD and BPF_SUBHarishankar Vishwanathan1-0/+161
The previous commit improves the precision in scalar(32)_min_max_add, and scalar(32)_min_max_sub. The improvement in precision occurs in cases when all outcomes overflow or underflow, respectively. This commit adds selftests that exercise those cases. This commit also adds selftests for cases where the output register state bounds for u(32)_min/u(32)_max are conservatively set to unbounded (when there is partial overflow or underflow). Signed-off-by: Harishankar Vishwanathan <harishankar.vishwanathan@gmail.com> Co-developed-by: Matan Shachnai <m.shachnai@rutgers.edu> Signed-off-by: Matan Shachnai <m.shachnai@rutgers.edu> Suggested-by: Eduard Zingerman <eddyz87@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250623040359.343235-3-harishankar.vishwanathan@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-24selftests/bpf: Convert test_sysctl to prog_testsJerome Marchand3-33/+10
Convert test_sysctl test to prog_tests with minimal change to the tests themselves. Signed-off-by: Jerome Marchand <jmarchan@redhat.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250619140603.148942-3-jmarchan@redhat.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-23selftests/bpf: Support ppc64el in vmtestLuis Gerhorst2-0/+102
With a rootfs built using libbpf's BPF CI [1], we can run specific tests as follows: $ ../libbpf-ci/rootfs/mkrootfs_debian.sh --arch ppc64el --distro noble $ PLATFORM=ppc64el CROSS_COMPILE=powerpc64le-linux-gnu- \ tools/testing/selftests/bpf/vmtest.sh \ -l libbpf-vmtest-rootfs-*-noble-ppc64el.tar.zst \ -- ./test_progs -t verifier_array_access Does not include a DENYLIST or support for KVM for now. [1] https://github.com/libbpf/ci Signed-off-by: Luis Gerhorst <luis.gerhorst@fau.de> Link: https://lore.kernel.org/r/20250619140854.2135283-1-luis.gerhorst@fau.de Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-23selftests/bpf: Add tests for bpf_cgroup_read_xattrSong Liu4-0/+366
Add tests for different scenarios with bpf_cgroup_read_xattr: 1. Read cgroup xattr from bpf_cgroup_from_id; 2. Read cgroup xattr from bpf_cgroup_ancestor; 3. Read cgroup xattr from css_iter; 4. Use bpf_cgroup_read_xattr in LSM hook security_socket_connect. 5. Use bpf_cgroup_read_xattr in cgroup program. Signed-off-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/20250623063854.1896364-5-song@kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-20selftests/bpf: Add test for bpftool access to read-only protected mapsSlava Imameev4-0/+490
Add selftest cases that validate bpftool's expected behavior when accessing maps protected from modification via security_bpf_map. The test includes a BPF program attached to security_bpf_map with two maps: - A protected map that only allows read-only access - An unprotected map that allows full access The test script attaches the BPF program to security_bpf_map and verifies that for the bpftool map command: - Read access works on both maps - Write access fails on the protected map - Write access succeeds on the unprotected map - These behaviors remain consistent when the maps are pinned Signed-off-by: Slava Imameev <slava.imameev@crowdstrike.com> Reviewed-by: Quentin Monnet <qmo@kernel.org> Link: https://lore.kernel.org/r/20250620151812.13952-2-slava.imameev@crowdstrike.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-19bpf: Adjust free target to avoid global starvation of LRU mapWillem de Bruijn1-37/+35
BPF_MAP_TYPE_LRU_HASH can recycle most recent elements well before the map is full, due to percpu reservations and force shrink before neighbor stealing. Once a CPU is unable to borrow from the global map, it will once steal one elem from a neighbor and after that each time flush this one element to the global list and immediately recycle it. Batch value LOCAL_FREE_TARGET (128) will exhaust a 10K element map with 79 CPUs. CPU 79 will observe this behavior even while its neighbors hold 78 * 127 + 1 * 15 == 9921 free elements (99%). CPUs need not be active concurrently. The issue can appear with affinity migration, e.g., irqbalance. Each CPU can reserve and then hold onto its 128 elements indefinitely. Avoid global list exhaustion by limiting aggregate percpu caches to half of map size, by adjusting LOCAL_FREE_TARGET based on cpu count. This change has no effect on sufficiently large tables. Similar to LOCAL_NR_SCANS and lru->nr_scans, introduce a map variable lru->free_target. The extra field fits in a hole in struct bpf_lru. The cacheline is already warm where read in the hot path. The field is only accessed with the lru lock held. Tested-by: Anton Protopopov <a.s.protopopov@gmail.com> Signed-off-by: Willem de Bruijn <willemb@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://lore.kernel.org/r/20250618215803.3587312-1-willemdebruijn.kernel@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-18selftests/bpf: include limits.h needed for PATH_MAX directlyEduard Zingerman1-0/+1
Constant PATH_MAX is used in function unpriv_helpers.c:open_config(). This constant is provided by include file <limits.h>. The dependency was added by commit [1], which does not include <limits.h> directly, relying instead on <limits.h> being included from zlib.h -> zconf.h. As it turns out, this is not the case for all systems, e.g. on Fedora 41 zlib 1.3.1 is used, and there <limits.h> is not included from zconf.h. Hence, there is a compilation error on Fedora 41. [1] commit fc2915bb8bfc ("selftests/bpf: More precise cpu_mitigations state detection") Fixes: fc2915bb8bfc ("selftests/bpf: More precise cpu_mitigations state detection") Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Acked-by: Viktor Malik <vmalik@redhat.com> Link: https://lore.kernel.org/r/20250618093134.3078870-1-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-18bpf: Fix key serial argument of bpf_lookup_user_key()James Bottomley6-8/+9
The underlying lookup_user_key() function uses a signed 32 bit integer for key serial numbers because legitimate serial numbers are positive (and > 3) and keyrings are negative. Using a u32 for the keyring in the bpf function doesn't currently cause any conversion problems but will start to trip the signed to unsigned conversion warnings when the kernel enables them, so convert the argument to signed (and update the tests accordingly) before it acquires more users. Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com> Reviewed-by: Roberto Sassu <roberto.sassu@huawei.com> Link: https://lore.kernel.org/r/84cdb0775254d297d75e21f577089f64abdfbd28.camel@HansenPartnership.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-17selftests/bpf: Fix unintentional switch case fall throughMykyta Yatsenko1-0/+1
Break from switch expression after parsing -n CLI argument in veristat, instead of falling through and enabling comparison mode. Fixes: a5c57f81eb2b ("veristat: add ability to set BPF_F_TEST_SANITY_STRICT flag with -r flag") Signed-off-by: Mykyta Yatsenko <yatsenko@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/bpf/20250617121536.1320074-1-mykyta.yatsenko5@gmail.com
2025-06-17selftests/bpf: More precise cpu_mitigations state detectionEduard Zingerman1-3/+90
test_progs and test_verifier binaries execute unpriv tests under the following conditions: - unpriv BPF is enabled; - CPU mitigations are enabled (see [1] for details). The detection of the "mitigations enabled" state is performed by unpriv_helpers.c:get_mitigations_off() via inspecting kernel boot command line, looking for a parameter "mitigations=off". Such detection scheme won't work for certain configurations, e.g. when CONFIG_CPU_MITIGATIONS is disabled and boot parameter is not supplied. Miss-detection leads to test_progs executing tests meant to be run only with mitigations enabled, e.g. verifier_and.c:known_subreg_with_unknown_reg(), and reporting false failures. Internally, verifier sets bpf_verifier_env->bypass_spec_{v1,v4} basing on the value returned by kernel/cpu.c:cpu_mitigations_off(). This function is backed by a variable kernel/cpu.c:cpu_mitigations. This state is not fully introspect-able via sysfs. The closest proxy is /sys/devices/system/cpu/vulnerabilities/spectre_v1, but it reports "vulnerable" state only if mitigations are disabled *and* current cpu is vulnerable, while verifier does not check cpu state. There are only two ways the kernel/cpu.c:cpu_mitigations can be set: - via boot parameter; - via CONFIG_CPU_MITIGATIONS option. This commit updates unpriv_helpers.c:get_mitigations_off() to scan /boot/config-$(uname -r) and /proc/config.gz for CONFIG_CPU_MITIGATIONS value in addition to boot command line check. Tested using the following configurations: - mitigations enabled (unpriv tests are enabled) - mitigations disabled via boot cmdline (unpriv tests skipped) - mitigations disabled via CONFIG_CPU_MITIGATIONS (unpriv tests skipped) [1] https://lore.kernel.org/bpf/20231025031144.5508-1-laoar.shao@gmail.com/ Reported-by: Mykyta Yatsenko <mykyta.yatsenko5@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250617005710.1066165-2-eddyz87@gmail.com
2025-06-17selftests/bpf: Fix RELEASE build failure with gcc14Yonghong Song4-5/+9
With gcc14, when building with RELEASE=1, I hit four below compilation failure: Error 1: In file included from test_loader.c:6: test_loader.c: In function ‘run_subtest’: test_progs.h:194:17: error: ‘retval’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 194 | fprintf(stdout, ##format); \ | ^~~~~~~ test_loader.c:958:13: note: ‘retval’ was declared here 958 | int retval, err, i; | ^~~~~~ The uninitialized var 'retval' actually could cause incorrect result. Error 2: In function ‘test_fd_array_cnt’: prog_tests/fd_array.c:71:14: error: ‘btf_id’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 71 | fd = bpf_btf_get_fd_by_id(id); | ^~~~~~~~~~~~~~~~~~~~~~~~ prog_tests/fd_array.c:302:15: note: ‘btf_id’ was declared here 302 | __u32 btf_id; | ^~~~~~ Changing ASSERT_GE to ASSERT_EQ can fix the compilation error. Otherwise, there is no functionality change. Error 3: prog_tests/tailcalls.c: In function ‘test_tailcall_hierarchy_count’: prog_tests/tailcalls.c:1402:23: error: ‘fentry_data_fd’ may be used uninitialized in this function [-Werror=maybe-uninitialized] 1402 | err = bpf_map_lookup_elem(fentry_data_fd, &i, &val); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The code is correct. The change intends to silence gcc errors. Error 4: (this error only happens on arm64) In file included from prog_tests/log_buf.c:4: prog_tests/log_buf.c: In function ‘bpf_prog_load_log_buf’: ./test_progs.h:390:22: error: ‘log_buf’ may be used uninitialized [-Werror=maybe-uninitialized] 390 | int ___err = libbpf_get_error(___res); \ | ^~~~~~~~~~~~~~~~~~~~~~~~ prog_tests/log_buf.c:158:14: note: in expansion of macro ‘ASSERT_OK_PTR’ 158 | if (!ASSERT_OK_PTR(log_buf, "log_buf_alloc")) | ^~~~~~~~~~~~~ In file included from selftests/bpf/tools/include/bpf/bpf.h:32, from ./test_progs.h:36: selftests/bpf/tools/include/bpf/libbpf_legacy.h:113:17: note: by argument 1 of type ‘const void *’ to ‘libbpf_get_error’ declared here 113 | LIBBPF_API long libbpf_get_error(const void *ptr); | ^~~~~~~~~~~~~~~~ Adding a pragma to disable maybe-uninitialized fixed the issue. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250617044956.2686668-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-17bpf: Mark dentry->d_inode as trusted_or_nullSong Liu2-0/+33
LSM hooks such as security_path_mknod() and security_inode_rename() have access to newly allocated negative dentry, which has NULL d_inode. Therefore, it is necessary to do the NULL pointer check for d_inode. Also add selftests that checks the verifier enforces the NULL pointer check. Signed-off-by: Song Liu <song@kernel.org> Reviewed-by: Matt Bobrowski <mattbobrowski@google.com> Link: https://lore.kernel.org/r/20250613052857.1992233-1-song@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-13selftests/bpf: verify jset handling in CFG computationEduard Zingerman1-0/+16
A test case to check if both branches of jset are explored when computing program CFG. At 'if r1 & 0x7 ...': - register 'r2' is computed alive only if jump branch of jset instruction is followed; - register 'r0' is computed alive only if fallthrough branch of jset instruction is followed. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250613175331.3238739-2-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-13veristat: Memory accounting for bpf programsEduard Zingerman2-7/+246
This commit adds a new field mem_peak / "Peak memory (MiB)" field to a set of gathered statistics. The field is intended as an estimate for peak verifier memory consumption for processing of a given program. Mechanically stat is collected as follows: - At the beginning of handle_verif_mode() a new cgroup is created and veristat process is moved into this cgroup. - At each program load: - bpf_object__load() is split into bpf_object__prepare() and bpf_object__load() to avoid accounting for memory allocated for maps; - before bpf_object__load(): - a write to "memory.peak" file of the new cgroup is used to reset cgroup statistics; - updated value is read from "memory.peak" file and stashed; - after bpf_object__load() "memory.peak" is read again and difference between new and stashed values is used as a metric. If any of the above steps fails veristat proceeds w/o collecting mem_peak information for a program, reporting mem_peak as -1. While memcg provides data in bytes (converted from pages), veristat converts it to megabytes to avoid jitter when comparing results of different executions. The change has no measurable impact on veristat running time. A correlation between "Peak states" and "Peak memory" fields provides a sanity check for gathered statistics, e.g. a sample of data for sched_ext programs: Program Peak states Peak memory (MiB) ------------------------ ----------- ----------------- lavd_select_cpu 2153 44 lavd_enqueue 1982 41 lavd_dispatch 3480 28 layered_dispatch 1417 17 layered_enqueue 760 11 lavd_cpu_offline 349 6 lavd_cpu_online 349 6 lavd_init 394 6 rusty_init 350 5 layered_select_cpu 391 4 ... rusty_stopping 134 1 arena_topology_node_init 170 0 Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250613072147.3938139-3-eddyz87@gmail.com
2025-06-13bpf/veristat: Fix veristat for map type BPF_MAP_TYPE_CGRP_STORAGESong Liu1-0/+1
BPF_MAP_TYPE_CGRP_STORAGE doesn't allow non-zero max_entries. So veristat should not set it to 1. Signed-off-by: Song Liu <song@kernel.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250613050001.1058733-1-song@kernel.org
2025-06-13selftests/bpf: Fix xdp_do_redirect failure with 64KB page sizeYonghong Song1-2/+11
On arm64 with 64KB page size, the selftest xdp_do_redirect failed like below: ... test_xdp_do_redirect:PASS:pkt_count_tc 0 nsec test_max_pkt_size:PASS:prog_run_max_size 0 nsec test_max_pkt_size:FAIL:prog_run_too_big unexpected prog_run_too_big: actual -28 != expected -22 With 64KB page size, the xdp frame size will be much bigger so the existing test will fail. Adjust various parameters so the test can also work on 64K page size. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250612035042.2208630-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-13selftests/bpf: Fix two net related test failures with 64K page sizeYonghong Song2-9/+14
When running BPF selftests on arm64 with a 64K page size, I encountered the following two test failures: sockmap_basic/sockmap skb_verdict change tail:FAIL tc_change_tail:FAIL With further debugging, I identified the root cause in the following kernel code within __bpf_skb_change_tail(): u32 max_len = BPF_SKB_MAX_LEN; u32 min_len = __bpf_skb_min_len(skb); int ret; if (unlikely(flags || new_len > max_len || new_len < min_len)) return -EINVAL; With a 4K page size, new_len = 65535 and max_len = 16064, the function returns -EINVAL. However, With a 64K page size, max_len increases to 261824, allowing execution to proceed further in the function. This is because BPF_SKB_MAX_LEN scales with the page size and larger page sizes result in higher max_len values. Updating the new_len parameter in both tests based on actual kernel page size resolved both failures. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250612035037.2207911-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-13bpf: Fix an issue in bpf_prog_test_run_xdp when page size greater than 4KYonghong Song2-8/+96
The bpf selftest xdp_adjust_tail/xdp_adjust_frags_tail_grow failed on arm64 with 64KB page: xdp_adjust_tail/xdp_adjust_frags_tail_grow:FAIL In bpf_prog_test_run_xdp(), the xdp->frame_sz is set to 4K, but later on when constructing frags, with 64K page size, the frag data_len could be more than 4K. This will cause problems in bpf_xdp_frags_increase_tail(). To fix the failure, the xdp->frame_sz is set to be PAGE_SIZE so kernel can test different page size properly. With the kernel change, the user space and bpf prog needs adjustment. Currently, the MAX_SKB_FRAGS default value is 17, so for 4K page, the maximum packet size will be less than 68K. To test 64K page, a bigger maximum packet size than 68K is desired. So two different functions are implemented for subtest xdp_adjust_frags_tail_grow. Depending on different page size, different data input/output sizes are used to adapt with different page size. Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250612035032.2207498-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-13selftests/bpf: fix signedness bug in redir_partial()Fushuai Wang1-0/+2
When xsend() returns -1 (error), the check 'n < sizeof(buf)' incorrectly treats it as success due to unsigned promotion. Explicitly check for -1 first. Fixes: a4b7193d8efd ("selftests/bpf: Add sockmap test for redirecting partial skb data") Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Link: https://lore.kernel.org/r/20250612084208.27722-1-wangfushuai@baidu.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-13selftests/bpf: tests with a loop state missing read/precision markEduard Zingerman1-0/+277
The test case absent_mark_in_the_middle_state is equivalent of the following C program: 1: r8 = bpf_get_prandom_u32(); 2: r6 = -32; 3: bpf_iter_num_new(&fp[-8], 0, 10); 4: if (unlikely(bpf_get_prandom_u32())) 5: r6 = -31; 6: for (;;) { 7: if (!bpf_iter_num_next(&fp[-8])) 8: break; 9: if (unlikely(bpf_get_prandom_u32())) 10: *(u64 *)(fp + r6) = 7; 11: } 12: bpf_iter_num_destroy(&fp[-8]); 13: return 0; W/o a fix that instructs verifier to ignore branches count for loop entries verification proceeds as follows: - 1-4, state is {r6=-32,fp-8=active}; - 6, checkpoint A is created with {r6=-32,fp-8=active}; - 7, checkpoint B is created with {r6=-32,fp-8=active}, push state {r6=-32,fp-8=active} from 7 to 9; - 8,12,13, {r6=-32,fp-8=drained}, exit; - pop state with {r6=-32,fp-8=active} from 7 to 9; - 9, push state {r6=-32,fp-8=active} from 9 to 10; - 6, checkpoint C is created with {r6=-32,fp-8=active}; - 7, checkpoint A is hit, no precision propagated for r6 to C; - pop state {r6=-32,fp-8=active} from 9 to 10; - 10, state is {r6=-31,fp-8=active}, r6 is marked as read and precise, these marks are propagated to checkpoints A and B (but not C, as it is not the parent of current state; - 6, {r6=-31,fp-8=active} checkpoint C is hit, because r6 is not marked precise for this checkpoint; - the program is accepted, despite a possibility of unaligned u64 stack access at offset -31. The test case absent_mark_in_the_middle_state2 is similar except the following change: r8 = bpf_get_prandom_u32(); r6 = -32; bpf_iter_num_new(&fp[-8], 0, 10); if (unlikely(bpf_get_prandom_u32())) { r6 = -31; + jump_into_loop: + goto +0; + goto loop; + } + if (unlikely(bpf_get_prandom_u32())) + goto jump_into_loop; + loop: for (;;) { if (!bpf_iter_num_next(&fp[-8])) break; if (unlikely(bpf_get_prandom_u32())) *(u64 *)(fp + r6) = 7; } bpf_iter_num_destroy(&fp[-8]) return 0 The goal is to check that read/precision marks are propagated to checkpoint created at 'goto +0' that resides outside of the loop. The test case absent_mark_in_the_middle_state3 is a bit different and is equivalent to the C program below: int absent_mark_in_the_middle_state3(void) { bpf_iter_num_new(&fp[-8], 0, 10) loop1(-32, &fp[-8]) loop1_wrapper(&fp[-8]) bpf_iter_num_destroy(&fp[-8]) } int loop1(num, iter) { while (bpf_iter_num_next(iter)) { if (unlikely(bpf_get_prandom_u32())) *(fp + num) = 7; } return 0 } int loop1_wrapper(iter) { r6 = -32; if (unlikely(bpf_get_prandom_u32())) r6 = -31; loop1(r6, iter); return 0; } The unsafe state is reached in a similar manner, but the loop is located inside a subprogram that is called from two locations in the main subprogram. This detail is important for exercising bpf_scc_visit->backedges memory management. Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20250611200836.4135542-11-eddyz87@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-11selftests/bpf: Fix cgroup_mprog_ordering failure due to uninitialized variableYonghong Song1-1/+1
On arm64, the cgroup_mprog_ordering selftest failed with test_progs run when building with clang compiler. The reason is due to socklen_t optlen not initialized. In kernel function do_ip_getsockopt(), we have if (copy_from_sockptr(&len, optlen, sizeof(int))) return -EFAULT; if (len < 0) return -EINVAL; The above 'len' variable is a negative value and hence the test failed. But the test is okay on x86_64. I checked the x86_64 asm code and I didn't see explicit initialization of 'optlen' but its value is 0 so kernel didn't return error. This should be a pure luck. Fix the bug by initializing 'oplen' var properly. Fixes: e422d5f118e4 ("selftests/bpf: Add two selftests for mprog API based cgroup progs") Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20250611162103.1623692-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-11selftests/bpf: Add test to cover ktls with bpf_msg_pop_dataJiayuan Chen2-0/+95
The selftest can reproduce an issue where using bpf_msg_pop_data() in ktls causes errors on the receiving end. Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20250609020910.397930-3-jiayuan.chen@linux.dev
2025-06-10selftests/bpf: Add test for Spectre v1 mitigationLuis Gerhorst1-0/+57
This is based on the gadget from the description of commit 9183671af6db ("bpf: Fix leakage under speculation on mispredicted branches"). Signed-off-by: Luis Gerhorst <luis.gerhorst@fau.de> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Link: https://lore.kernel.org/r/20250603212814.338867-1-luis.gerhorst@fau.de Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-10bpf: Fall back to nospec for Spectre v1Luis Gerhorst9-50/+109
This implements the core of the series and causes the verifier to fall back to mitigating Spectre v1 using speculation barriers. The approach was presented at LPC'24 [1] and RAID'24 [2]. If we find any forbidden behavior on a speculative path, we insert a nospec (e.g., lfence speculation barrier on x86) before the instruction and stop verifying the path. While verifying a speculative path, we can furthermore stop verification of that path whenever we encounter a nospec instruction. A minimal example program would look as follows: A = true B = true if A goto e f() if B goto e unsafe() e: exit There are the following speculative and non-speculative paths (`cur->speculative` and `speculative` referring to the value of the push_stack() parameters): - A = true - B = true - if A goto e - A && !cur->speculative && !speculative - exit - !A && !cur->speculative && speculative - f() - if B goto e - B && cur->speculative && !speculative - exit - !B && cur->speculative && speculative - unsafe() If f() contains any unsafe behavior under Spectre v1 and the unsafe behavior matches `state->speculative && error_recoverable_with_nospec(err)`, do_check() will now add a nospec before f() instead of rejecting the program: A = true B = true if A goto e nospec f() if B goto e unsafe() e: exit Alternatively, the algorithm also takes advantage of nospec instructions inserted for other reasons (e.g., Spectre v4). Taking the program above as an example, speculative path exploration can stop before f() if a nospec was inserted there because of Spectre v4 sanitization. In this example, all instructions after the nospec are dead code (and with the nospec they are also dead code speculatively). For this, it relies on the fact that speculation barriers generally prevent all later instructions from executing if the speculation was not correct: * On Intel x86_64, lfence acts as full speculation barrier, not only as a load fence [3]: An LFENCE instruction or a serializing instruction will ensure that no later instructions execute, even speculatively, until all prior instructions complete locally. [...] Inserting an LFENCE instruction after a bounds check prevents later operations from executing before the bound check completes. This was experimentally confirmed in [4]. * On AMD x86_64, lfence is dispatch-serializing [5] (requires MSR C001_1029[1] to be set if the MSR is supported, this happens in init_amd()). AMD further specifies "A dispatch serializing instruction forces the processor to retire the serializing instruction and all previous instructions before the next instruction is executed" [8]. As dispatch is not specific to memory loads or branches, lfence therefore also affects all instructions there. Also, if retiring a branch means it's PC change becomes architectural (should be), this means any "wrong" speculation is aborted as required for this series. * ARM's SB speculation barrier instruction also affects "any instruction that appears later in the program order than the barrier" [6]. * PowerPC's barrier also affects all subsequent instructions [7]: [...] executing an ori R31,R31,0 instruction ensures that all instructions preceding the ori R31,R31,0 instruction have completed before the ori R31,R31,0 instruction completes, and that no subsequent instructions are initiated, even out-of-order, until after the ori R31,R31,0 instruction completes. The ori R31,R31,0 instruction may complete before storage accesses associated with instructions preceding the ori R31,R31,0 instruction have been performed Regarding the example, this implies that `if B goto e` will not execute before `if A goto e` completes. Once `if A goto e` completes, the CPU should find that the speculation was wrong and continue with `exit`. If there is any other path that leads to `if B goto e` (and therefore `unsafe()`) without going through `if A goto e`, then a nospec will still be needed there. However, this patch assumes this other path will be explored separately and therefore be discovered by the verifier even if the exploration discussed here stops at the nospec. This patch furthermore has the unfortunate consequence that Spectre v1 mitigations now only support architectures which implement BPF_NOSPEC. Before this commit, Spectre v1 mitigations prevented exploits by rejecting the programs on all architectures. Because some JITs do not implement BPF_NOSPEC, this patch therefore may regress unpriv BPF's security to a limited extent: * The regression is limited to systems vulnerable to Spectre v1, have unprivileged BPF enabled, and do NOT emit insns for BPF_NOSPEC. The latter is not the case for x86 64- and 32-bit, arm64, and powerpc 64-bit and they are therefore not affected by the regression. According to commit a6f6a95f2580 ("LoongArch, bpf: Fix jit to skip speculation barrier opcode"), LoongArch is not vulnerable to Spectre v1 and therefore also not affected by the regression. * To the best of my knowledge this regression may therefore only affect MIPS. This is deemed acceptable because unpriv BPF is still disabled there by default. As stated in a previous commit, BPF_NOSPEC could be implemented for MIPS based on GCC's speculation_barrier implementation. * It is unclear which other architectures (besides x86 64- and 32-bit, ARM64, PowerPC 64-bit, LoongArch, and MIPS) supported by the kernel are vulnerable to Spectre v1. Also, it is not clear if barriers are available on these architectures. Implementing BPF_NOSPEC on these architectures therefore is non-trivial. Searching GCC and the kernel for speculation barrier implementations for these architectures yielded no result. * If any of those regressed systems is also vulnerable to Spectre v4, the system was already vulnerable to Spectre v4 attacks based on unpriv BPF before this patch and the impact is therefore further limited. As an alternative to regressing security, one could still reject programs if the architecture does not emit BPF_NOSPEC (e.g., by removing the empty BPF_NOSPEC-case from all JITs except for LoongArch where it appears justified). However, this will cause rejections on these archs that are likely unfounded in the vast majority of cases. In the tests, some are now successful where we previously had a false-positive (i.e., rejection). Change them to reflect where the nospec should be inserted (using __xlated_unpriv) and modify the error message if the nospec is able to mitigate a problem that previously shadowed another problem (in that case __xlated_unpriv does not work, therefore just add a comment). Define SPEC_V1 to avoid duplicating this ifdef whenever we check for nospec insns using __xlated_unpriv, define it here once. This also improves readability. PowerPC can probably also be added here. However, omit it for now because the BPF CI currently does not include a test. Limit it to EPERM, EACCES, and EINVAL (and not everything except for EFAULT and ENOMEM) as it already has the desired effect for most real-world programs. Briefly went through all the occurrences of EPERM, EINVAL, and EACCESS in verifier.c to validate that catching them like this makes sense. Thanks to Dustin for their help in checking the vendor documentation. [1] https://lpc.events/event/18/contributions/1954/ ("Mitigating Spectre-PHT using Speculation Barriers in Linux eBPF") [2] https://arxiv.org/pdf/2405.00078 ("VeriFence: Lightweight and Precise Spectre Defenses for Untrusted Linux Kernel Extensions") [3] https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/runtime-speculative-side-channel-mitigations.html ("Managed Runtime Speculative Execution Side Channel Mitigations") [4] https://dl.acm.org/doi/pdf/10.1145/3359789.3359837 ("Speculator: a tool to analyze speculative execution attacks and mitigations" - Section 4.6 "Stopping Speculative Execution") [5] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/software-techniques-for-managing-speculation.pdf ("White Paper - SOFTWARE TECHNIQUES FOR MANAGING SPECULATION ON AMD PROCESSORS - REVISION 5.09.23") [6] https://developer.arm.com/documentation/ddi0597/2020-12/Base-Instructions/SB--Speculation-Barrier- ("SB - Speculation Barrier - Arm Armv8-A A32/T32 Instruction Set Architecture (2020-12)") [7] https://wiki.raptorcs.com/w/images/5/5f/OPF_PowerISA_v3.1C.pdf ("Power ISA™ - Version 3.1C - May 26, 2024 - Section 9.2.1 of Book III") [8] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/40332.pdf ("AMD64 Architecture Programmer’s Manual Volumes 1–5 - Revision 4.08 - April 2024 - 7.6.4 Serializing Instructions") Signed-off-by: Luis Gerhorst <luis.gerhorst@fau.de> Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Acked-by: Henriette Herzog <henriette.herzog@rub.de> Cc: Dustin Nguyen <nguyen@cs.fau.de> Cc: Maximilian Ott <ott@cs.fau.de> Cc: Milan Stephan <milan.stephan@fau.de> Link: https://lore.kernel.org/r/20250603212428.338473-1-luis.gerhorst@fau.de Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2025-06-10selftests/bpf: Add cookies check for tracing fill_link_info testTao Chen1-1/+23
Adding tests for getting cookie with fill_link_info for tracing. Signed-off-by: Tao Chen <chen.dylane@linux.dev> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250606165818.3394397-2-chen.dylane@linux.dev
2025-06-10selftests/bpf: Add test cases with CONST_PTR_TO_MAP null checksIhor Solodrai1-0/+118
A test requires the following to happen: * CONST_PTR_TO_MAP value is checked for null * the code in the null branch fails verification Add test cases: * direct global map_ptr comparison to null * lookup inner map, then two checks (the first transforms map_value_or_null into map_ptr) * lookup inner map, spill-fill it, then check for null * use an array of ringbufs to recreate a common coding pattern [1] [1] https://lore.kernel.org/bpf/CAEf4BzZNU0gX_sQ8k8JaLe1e+Veth3Rk=4x7MDhv=hQxvO8EDw@mail.gmail.com/ Suggested-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Ihor Solodrai <isolodrai@meta.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250609183024.359974-4-isolodrai@meta.com
generated by cgit v1.2.3 (git 2.39.0) at 2025-08-12 09:27:40 +0300