1. 20 3月, 2018 2 次提交
  2. 15 3月, 2018 1 次提交
  3. 27 2月, 2018 2 次提交
  4. 24 2月, 2018 2 次提交
    • D
      bpf: add various jit test cases · 23d191a8
      Daniel Borkmann 提交于
      Add few test cases that check the rnu-time results under JIT.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      23d191a8
    • D
      bpf: allow xadd only on aligned memory · ca369602
      Daniel Borkmann 提交于
      The requirements around atomic_add() / atomic64_add() resp. their
      JIT implementations differ across architectures. E.g. while x86_64
      seems just fine with BPF's xadd on unaligned memory, on arm64 it
      triggers via interpreter but also JIT the following crash:
      
        [  830.864985] Unable to handle kernel paging request at virtual address ffff8097d7ed6703
        [...]
        [  830.916161] Internal error: Oops: 96000021 [#1] SMP
        [  830.984755] CPU: 37 PID: 2788 Comm: test_verifier Not tainted 4.16.0-rc2+ #8
        [  830.991790] Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.29 07/17/2017
        [  830.998998] pstate: 80400005 (Nzcv daif +PAN -UAO)
        [  831.003793] pc : __ll_sc_atomic_add+0x4/0x18
        [  831.008055] lr : ___bpf_prog_run+0x1198/0x1588
        [  831.012485] sp : ffff00001ccabc20
        [  831.015786] x29: ffff00001ccabc20 x28: ffff8017d56a0f00
        [  831.021087] x27: 0000000000000001 x26: 0000000000000000
        [  831.026387] x25: 000000c168d9db98 x24: 0000000000000000
        [  831.031686] x23: ffff000008203878 x22: ffff000009488000
        [  831.036986] x21: ffff000008b14e28 x20: ffff00001ccabcb0
        [  831.042286] x19: ffff0000097b5080 x18: 0000000000000a03
        [  831.047585] x17: 0000000000000000 x16: 0000000000000000
        [  831.052885] x15: 0000ffffaeca8000 x14: 0000000000000000
        [  831.058184] x13: 0000000000000000 x12: 0000000000000000
        [  831.063484] x11: 0000000000000001 x10: 0000000000000000
        [  831.068783] x9 : 0000000000000000 x8 : 0000000000000000
        [  831.074083] x7 : 0000000000000000 x6 : 000580d428000000
        [  831.079383] x5 : 0000000000000018 x4 : 0000000000000000
        [  831.084682] x3 : ffff00001ccabcb0 x2 : 0000000000000001
        [  831.089982] x1 : ffff8097d7ed6703 x0 : 0000000000000001
        [  831.095282] Process test_verifier (pid: 2788, stack limit = 0x0000000018370044)
        [  831.102577] Call trace:
        [  831.105012]  __ll_sc_atomic_add+0x4/0x18
        [  831.108923]  __bpf_prog_run32+0x4c/0x70
        [  831.112748]  bpf_test_run+0x78/0xf8
        [  831.116224]  bpf_prog_test_run_xdp+0xb4/0x120
        [  831.120567]  SyS_bpf+0x77c/0x1110
        [  831.123873]  el0_svc_naked+0x30/0x34
        [  831.127437] Code: 97fffe97 17ffffec 00000000 f9800031 (885f7c31)
      
      Reason for this is because memory is required to be aligned. In
      case of BPF, we always enforce alignment in terms of stack access,
      but not when accessing map values or packet data when the underlying
      arch (e.g. arm64) has CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS set.
      
      xadd on packet data that is local to us anyway is just wrong, so
      forbid this case entirely. The only place where xadd makes sense in
      fact are map values; xadd on stack is wrong as well, but it's been
      around for much longer. Specifically enforce strict alignment in case
      of xadd, so that we handle this case generically and avoid such crashes
      in the first place.
      
      Fixes: 17a52670 ("bpf: verifier (add verifier core)")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      ca369602
  5. 23 2月, 2018 1 次提交
    • D
      bpf, arm64: fix out of bounds access in tail call · 16338a9b
      Daniel Borkmann 提交于
      I recently noticed a crash on arm64 when feeding a bogus index
      into BPF tail call helper. The crash would not occur when the
      interpreter is used, but only in case of JIT. Output looks as
      follows:
      
        [  347.007486] Unable to handle kernel paging request at virtual address fffb850e96492510
        [...]
        [  347.043065] [fffb850e96492510] address between user and kernel address ranges
        [  347.050205] Internal error: Oops: 96000004 [#1] SMP
        [...]
        [  347.190829] x13: 0000000000000000 x12: 0000000000000000
        [  347.196128] x11: fffc047ebe782800 x10: ffff808fd7d0fd10
        [  347.201427] x9 : 0000000000000000 x8 : 0000000000000000
        [  347.206726] x7 : 0000000000000000 x6 : 001c991738000000
        [  347.212025] x5 : 0000000000000018 x4 : 000000000000ba5a
        [  347.217325] x3 : 00000000000329c4 x2 : ffff808fd7cf0500
        [  347.222625] x1 : ffff808fd7d0fc00 x0 : ffff808fd7cf0500
        [  347.227926] Process test_verifier (pid: 4548, stack limit = 0x000000007467fa61)
        [  347.235221] Call trace:
        [  347.237656]  0xffff000002f3a4fc
        [  347.240784]  bpf_test_run+0x78/0xf8
        [  347.244260]  bpf_prog_test_run_skb+0x148/0x230
        [  347.248694]  SyS_bpf+0x77c/0x1110
        [  347.251999]  el0_svc_naked+0x30/0x34
        [  347.255564] Code: 9100075a d280220a 8b0a002a d37df04b (f86b694b)
        [...]
      
      In this case the index used in BPF r3 is the same as in r1
      at the time of the call, meaning we fed a pointer as index;
      here, it had the value 0xffff808fd7cf0500 which sits in x2.
      
      While I found tail calls to be working in general (also for
      hitting the error cases), I noticed the following in the code
      emission:
      
        # bpftool p d j i 988
        [...]
        38:   ldr     w10, [x1,x10]
        3c:   cmp     w2, w10
        40:   b.ge    0x000000000000007c              <-- signed cmp
        44:   mov     x10, #0x20                      // #32
        48:   cmp     x26, x10
        4c:   b.gt    0x000000000000007c
        50:   add     x26, x26, #0x1
        54:   mov     x10, #0x110                     // #272
        58:   add     x10, x1, x10
        5c:   lsl     x11, x2, #3
        60:   ldr     x11, [x10,x11]                  <-- faulting insn (f86b694b)
        64:   cbz     x11, 0x000000000000007c
        [...]
      
      Meaning, the tests passed because commit ddb55992 ("arm64:
      bpf: implement bpf_tail_call() helper") was using signed compares
      instead of unsigned which as a result had the test wrongly passing.
      
      Change this but also the tail call count test both into unsigned
      and cap the index as u32. Latter we did as well in 90caccdd
      ("bpf: fix bpf_tail_call() x64 JIT") and is needed in addition here,
      too. Tested on HiSilicon Hi1616.
      
      Result after patch:
      
        # bpftool p d j i 268
        [...]
        38:	ldr	w10, [x1,x10]
        3c:	add	w2, w2, #0x0
        40:	cmp	w2, w10
        44:	b.cs	0x0000000000000080
        48:	mov	x10, #0x20                  	// #32
        4c:	cmp	x26, x10
        50:	b.hi	0x0000000000000080
        54:	add	x26, x26, #0x1
        58:	mov	x10, #0x110                 	// #272
        5c:	add	x10, x1, x10
        60:	lsl	x11, x2, #3
        64:	ldr	x11, [x10,x11]
        68:	cbz	x11, 0x0000000000000080
        [...]
      
      Fixes: ddb55992 ("arm64: bpf: implement bpf_tail_call() helper")
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      16338a9b
  6. 22 2月, 2018 3 次提交
  7. 15 2月, 2018 3 次提交
  8. 14 2月, 2018 2 次提交
    • Y
      tools/bpf: adjust rlimit RLIMIT_MEMLOCK for test_tcpbpf_user · 615a9474
      Yonghong Song 提交于
      The default rlimit RLIMIT_MEMLOCK is 64KB. In certain cases,
      e.g. in a test machine mimicking our production system, this test may
      fail due to unable to charge the required memory for map creation:
         # ./test_tcpbpf_user
         libbpf: failed to create map (name: 'global_map'): Operation not permitted
         libbpf: failed to load object 'test_tcpbpf_kern.o'
         FAILED: load_bpf_file failed for: test_tcpbpf_kern.o
      
      Changing the default rlimit RLIMIT_MEMLOCK to unlimited makes
      the test always pass.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      615a9474
    • J
      selftests/bpf: fix Makefile for cgroup_helpers.c · 41757dcb
      Jesper Dangaard Brouer 提交于
      The current selftests Makefile construct result in cgroup_helpers.c
      gets compiled together with all the TEST_GEN_PROGS. And it also result
      in invoking the libbpf Makefile two times (tools/lib/bpf).
      
      These issues were introduced in commit 9d1f1594 ("bpf: move
      cgroup_helpers from samples/bpf/ to tools/testing/selftesting/bpf/").
      
      The only test program that requires the cgroup helpers is 'test_dev_cgroup'.
      
      Thus, create a make target $(OUTPUT)/test_dev_cgroup that extend[1]
      the 'prerequisite' for the 'stem' %-style pattern in ../lib.mk,
      for this particular test program.
      
      Reviewers notice the make-rules in tools/testing/selftests/lib.mk
      differ from the normal kernel kbuild rules, and it is practical
      to use 'make -p' to follow how these 'Implicit/static pattern stem'
      gets expanded.
      
      [1] https://www.gnu.org/software/make/manual/html_node/Static-Usage.html
      
      Fixes: 9d1f1594 ("bpf: move cgroup_helpers from samples/bpf/ to tools/testing/selftesting/bpf/")
      Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      41757dcb
  9. 09 2月, 2018 2 次提交
  10. 08 2月, 2018 1 次提交
  11. 06 2月, 2018 1 次提交
    • Y
      tools/bpf: fix batch-mode test failure of test_xdp_redirect.sh · 7b4eb53d
      Yonghong Song 提交于
      The tests at tools/testing/selftests/bpf can run in patch mode, e.g.,
          make -C tools/testing/selftests/bpf run_tests
      
      With the batch mode, I experimented intermittent test failure of
      test_xdp_redirect.sh.
          ....
          selftests: test_xdp_redirect [PASS]
          selftests: test_xdp_redirect.sh [PASS]
          RTNETLINK answers: File exists
          selftests: test_xdp_meta [FAILED]
          selftests: test_xdp_meta.sh [FAIL]
          ....
      
      The following illustrates what caused the failure:
           (1). test_xdp_redirect creates veth pairs (veth1,veth11) and
                (veth2,veth22), and assign veth11 and veth22 to namespace
                ns1 and ns2 respectively.
           (2). at the end of test_xdp_redirect test, ns1 and ns2 are
                deleted. During this process, the deletion of actual
                namespace resources, including deletion of veth1{1} and veth2{2},
                is put into a workqueue to be processed asynchronously.
           (3). test_xdp_meta tries to create veth pair (veth1, veth2).
                The previous veth deletions in step (2) have not finished yet,
                and veth1 or veth2 may be still valid in the kernel, thus
                causing the failure.
      
      The fix is to explicitly delete the veth pair before test_xdp_redirect
      exits. Only one end of veth needs deletion as the kernel will delete
      the other end automatically. Also test_xdp_meta is also fixed in
      similar manner to avoid future potential issues.
      
      Fixes: 996139e8 ("selftests: bpf: add a test for XDP redirect")
      Fixes: 22c88526 ("bpf: improve selftests and add tests for meta pointer")
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      7b4eb53d
  12. 01 2月, 2018 2 次提交
    • D
      bpf: fix null pointer deref in bpf_prog_test_run_xdp · 65073a67
      Daniel Borkmann 提交于
      syzkaller was able to generate the following XDP program ...
      
        (18) r0 = 0x0
        (61) r5 = *(u32 *)(r1 +12)
        (04) (u32) r0 += (u32) 0
        (95) exit
      
      ... and trigger a NULL pointer dereference in ___bpf_prog_run()
      via bpf_prog_test_run_xdp() where this was attempted to run.
      
      Reason is that recent xdp_rxq_info addition to XDP programs
      updated all drivers, but not bpf_prog_test_run_xdp(), where
      xdp_buff is set up. Thus when context rewriter does the deref
      on the netdev it's NULL at runtime. Fix it by using xdp_rxq
      from loopback dev. __netif_get_rx_queue() helper can also be
      reused in various other locations later on.
      
      Fixes: 02dd3291 ("bpf: finally expose xdp_rxq_info to XDP bpf-programs")
      Reported-by: syzbot+1eb094057b338eb1fc00@syzkaller.appspotmail.com
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Acked-by: NJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      65073a67
    • Y
      tools/bpf: permit selftests/bpf to be built in a different directory · 62a06994
      Yonghong Song 提交于
      Fix a couple of issues at tools/testing/selftests/bpf/Makefile so
      the following command
         make -C tools/testing/selftests/bpf OUTPUT=/home/yhs/tmp
      can put the built results into a different directory.
      
      Also add the built binary test_tcpbpf_user in the .gitignore file.
      
      Fixes: 6882804c ("selftests/bpf: add a test for overlapping packet range checks")
      Fixes: 9d1f1594 ("bpf: move cgroup_helpers from samples/bpf/ to tools/testing/selftesting/bpf/")
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      62a06994
  13. 27 1月, 2018 3 次提交
  14. 26 1月, 2018 3 次提交
  15. 24 1月, 2018 8 次提交
  16. 20 1月, 2018 3 次提交
  17. 19 1月, 2018 1 次提交