1. 30 Jan, 2019 1 commit
  2. 15 Jan, 2019 1 commit
    • Yonghong Song's avatar
      samples/bpf: workaround clang asm goto compilation errors · 6bf3bbe1
      Yonghong Song authored
      x86 compilation has required asm goto support since 4.17.
      Since clang does not support asm goto, at 4.17,
      Commit b1ae32db ("x86/cpufeature: Guard asm_volatile_goto usage
      for BPF compilation") worked around the issue by permitting an
      alternative implementation without asm goto for clang.
      
      At 5.0, more asm goto usages appeared.
        [yhs@148 x86]$ egrep -r asm_volatile_goto
        include/asm/cpufeature.h:     asm_volatile_goto("1: jmp 6f\n"
        include/asm/jump_label.h:     asm_volatile_goto("1:"
        include/asm/jump_label.h:     asm_volatile_goto("1:"
        include/asm/rmwcc.h:  asm_volatile_goto (fullop "; j" #cc " %l[cc_label]"     \
        include/asm/uaccess.h:        asm_volatile_goto("\n"                          \
        include/asm/uaccess.h:        asm_volatile_goto("\n"                          \
        [yhs@148 x86]$
      
      Compiling samples/bpf directories, most bpf programs failed
      compilation with error messages like:
        In file included from /home/yhs/work/bpf-next/samples/bpf/xdp_sample_pkts_kern.c:2:
        In file included from /home/yhs/work/bpf-next/include/linux/ptrace.h:6:
        In file included from /home/yhs/work/bpf-next/include/linux/sched.h:15:
        In file included from /home/yhs/work/bpf-next/include/linux/sem.h:5:
        In file included from /home/yhs/work/bpf-next/include/uapi/linux/sem.h:5:
        In file included from /home/yhs/work/bpf-next/include/linux/ipc.h:9:
        In file included from /home/yhs/work/bpf-next/include/linux/refcount.h:72:
        /home/yhs/work/bpf-next/arch/x86/include/asm/refcount.h:70:9: error: 'asm goto' constructs are not supported yet
              return GEN_BINARY_SUFFIXED_RMWcc(LOCK_PREFIX "subl",
                     ^
        /home/yhs/work/bpf-next/arch/x86/include/asm/rmwcc.h:67:2: note: expanded from macro 'GEN_BINARY_SUFFIXED_RMWcc'
              __GEN_RMWcc(op " %[val], %[var]\n\t" suffix, var, cc,           \
              ^
        /home/yhs/work/bpf-next/arch/x86/include/asm/rmwcc.h:21:2: note: expanded from macro '__GEN_RMWcc'
              asm_volatile_goto (fullop "; j" #cc " %l[cc_label]"             \
              ^
        /home/yhs/work/bpf-next/include/linux/compiler_types.h:188:37: note: expanded from macro 'asm_volatile_goto'
        #define asm_volatile_goto(x...) asm goto(x)
      
      Most implementation does not even provide an alternative
      implementation. And it is also not practical to make changes
      for each call site.
      
      This patch workarounded the asm goto issue by redefining the macro like below:
        #define asm_volatile_goto(x...) asm volatile("invalid use of asm_volatile_goto")
      
      If asm_volatile_goto is not used by bpf programs, which is typically the case, nothing bad
      will happen. If asm_volatile_goto is used by bpf programs, which is incorrect, the compiler
      will issue an error since "invalid use of asm_volatile_goto" is not valid assembly codes.
      
      With this patch, all bpf programs under samples/bpf can pass compilation.
      
      Note that bpf programs under tools/testing/selftests/bpf/ compiled fine as
      they do not access kernel internal headers.
      
      Fixes: e769742d ("Revert "x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs"")
      Fixes: 18fe5822 ("x86, asm: change the GEN_*_RMWcc() macros to not quote the condition")
      Acked-by: 's avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarYonghong Song <yhs@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      6bf3bbe1
  3. 10 Jan, 2019 1 commit
  4. 08 Jan, 2019 1 commit
  5. 07 Jan, 2019 1 commit
  6. 23 Dec, 2018 2 commits
  7. 18 Dec, 2018 1 commit
  8. 17 Dec, 2018 1 commit
  9. 12 Dec, 2018 1 commit
    • Tycho Andersen's avatar
      samples: add an example of seccomp user trap · fec7b669
      Tycho Andersen authored
      The idea here is just to give a demonstration of how one could safely use
      the SECCOMP_RET_USER_NOTIF feature to do mount policies. This particular
      policy is (as noted in the comment) not very interesting, but it serves to
      illustrate how one might apply a policy dodging the various TOCTOU issues.
      Signed-off-by: 's avatarTycho Andersen <tycho@tycho.ws>
      CC: Kees Cook <keescook@chromium.org>
      CC: Andy Lutomirski <luto@amacapital.net>
      CC: Oleg Nesterov <oleg@redhat.com>
      CC: Eric W. Biederman <ebiederm@xmission.com>
      CC: "Serge E. Hallyn" <serge@hallyn.com>
      CC: Christian Brauner <christian@brauner.io>
      CC: Tyler Hicks <tyhicks@canonical.com>
      CC: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
      Signed-off-by: 's avatarKees Cook <keescook@chromium.org>
      fec7b669
  10. 03 Dec, 2018 2 commits
  11. 01 Dec, 2018 3 commits
  12. 23 Nov, 2018 1 commit
    • Daniel T. Lee's avatar
      samples: bpf: fix: error handling regarding kprobe_events · 5a863813
      Daniel T. Lee authored
      Currently, kprobe_events failure won't be handled properly.
      Due to calling system() indirectly to write to kprobe_events,
      it can't be identified whether an error is derived from kprobe or system.
      
          // buf = "echo '%c:%s %s' >> /s/k/d/t/kprobe_events"
          err = system(buf);
          if (err < 0) {
              printf("failed to create kprobe ..");
              return -1;
          }
      
      For example, running ./tracex7 sample in ext4 partition,
      "echo p:open_ctree open_ctree >> /s/k/d/t/kprobe_events"
      gets 256 error code system() failure.
      => The error comes from kprobe, but it's not handled correctly.
      
      According to man of system(3), it's return value
      just passes the termination status of the child shell
      rather than treating the error as -1. (don't care success)
      
      Which means, currently it's not working as desired.
      (According to the upper code snippet)
      
          ex) running ./tracex7 with ext4 env.
          # Current Output
          sh: echo: I/O error
          failed to open event open_ctree
      
          # Desired Output
          failed to create kprobe 'open_ctree' error 'No such file or directory'
      
      The problem is, error can't be verified whether from child ps
      or system. But using write() directly can verify the command
      failure, and it will treat all error as -1. So I suggest using
      write() directly to 'kprobe_events' rather than calling system().
      Signed-off-by: Daniel T. Lee's avatarDaniel T. Lee <danieltimlee@gmail.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      5a863813
  13. 20 Nov, 2018 2 commits
  14. 07 Nov, 2018 1 commit
  15. 11 Oct, 2018 1 commit
  16. 10 Oct, 2018 1 commit
  17. 04 Oct, 2018 1 commit
    • Bo YU's avatar
      bpf, tracex3_user: erase "ARRAY_SIZE" redefined · 20cdeb54
      Bo YU authored
      There is a warning when compiling bpf sample programs in sample/bpf:
      
        make -C /home/foo/bpf/samples/bpf/../../tools/lib/bpf/ RM='rm -rf' LDFLAGS= srctree=/home/foo/bpf/samples/bpf/../../ O=
          HOSTCC  /home/foo/bpf/samples/bpf/tracex3_user.o
        /home/foo/bpf/samples/bpf/tracex3_user.c:20:0: warning: "ARRAY_SIZE" redefined
         #define ARRAY_SIZE(x) (sizeof(x) / sizeof(*(x)))
      
        In file included from /home/foo/bpf/samples/bpf/tracex3_user.c:18:0:
        ./tools/testing/selftests/bpf/bpf_util.h:48:0: note: this is the location of the previous definition
         # define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
      Signed-off-by: 's avatarBo YU <tsu.yubo@gmail.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      20cdeb54
  18. 02 Oct, 2018 1 commit
  19. 01 Oct, 2018 1 commit
    • Roman Gushchin's avatar
      samples/bpf: extend test_cgrp2_attach2 test to use per-cpu cgroup storage · 5fcbd29b
      Roman Gushchin authored
      This commit extends the test_cgrp2_attach2 test to cover per-cpu
      cgroup storage. Bpf program will use shared and per-cpu cgroup
      storages simultaneously, so a better coverage of corresponding
      core code will be achieved.
      
      Expected output:
        $ ./test_cgrp2_attach2
        Attached DROP prog. This ping in cgroup /foo should fail...
        ping: sendmsg: Operation not permitted
        Attached DROP prog. This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS prog. This ping in cgroup /foo/bar should pass...
        Detached PASS from /foo/bar while DROP is attached to /foo.
        This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS from /foo/bar and detached DROP from /foo.
        This ping in cgroup /foo/bar should pass...
        ### override:PASS
        ### multi:PASS
      Signed-off-by: 's avatarRoman Gushchin <guro@fb.com>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      5fcbd29b
  20. 21 Sep, 2018 1 commit
    • Prashant Bhole's avatar
      samples/bpf: fix compilation failure · 32c00979
      Prashant Bhole authored
      following commit:
      commit d58e468b ("flow_dissector: implements flow dissector BPF hook")
      added struct bpf_flow_keys which conflicts with the struct with
      same name in sockex2_kern.c and sockex3_kern.c
      
      similar to commit:
      commit 534e0e52 ("samples/bpf: fix a compilation failure")
      we tried the rename it "flow_keys" but it also conflicted with struct
      having same name in include/net/flow_dissector.h. Hence renaming the
      struct to "flow_key_record". Also, this commit doesn't fix the
      compilation error completely because the similar struct is present in
      sockex3_kern.c. Hence renaming it in both files sockex3_user.c and
      sockex3_kern.c
      Signed-off-by: 's avatarPrashant Bhole <bhole_prashant_q7@lab.ntt.co.jp>
      Acked-by: 's avatarSong Liu <songliubraving@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      32c00979
  21. 18 Sep, 2018 2 commits
  22. 31 Aug, 2018 2 commits
  23. 29 Aug, 2018 1 commit
  24. 16 Aug, 2018 1 commit
  25. 10 Aug, 2018 2 commits
  26. 09 Aug, 2018 1 commit
  27. 02 Aug, 2018 1 commit
    • Roman Gushchin's avatar
      samples/bpf: extend test_cgrp2_attach2 test to use cgroup storage · 28ba0687
      Roman Gushchin authored
      The test_cgrp2_attach test covers bpf cgroup attachment code well,
      so let's re-use it for testing allocation/releasing of cgroup storage.
      
      The extension is pretty straightforward: the bpf program will use
      the cgroup storage to save the number of transmitted bytes.
      
      Expected output:
        $ ./test_cgrp2_attach2
        Attached DROP prog. This ping in cgroup /foo should fail...
        ping: sendmsg: Operation not permitted
        Attached DROP prog. This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS prog. This ping in cgroup /foo/bar should pass...
        Detached PASS from /foo/bar while DROP is attached to /foo.
        This ping in cgroup /foo/bar should fail...
        ping: sendmsg: Operation not permitted
        Attached PASS from /foo/bar and detached DROP from /foo.
        This ping in cgroup /foo/bar should pass...
        ### override:PASS
        ### multi:PASS
      Signed-off-by: 's avatarRoman Gushchin <guro@fb.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Acked-by: 's avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: 's avatarDaniel Borkmann <daniel@iogearbox.net>
      28ba0687
  28. 27 Jul, 2018 4 commits
  29. 17 Jul, 2018 1 commit