1. 22 Nov, 2017 2 commits
  2. 21 Nov, 2017 4 commits
  3. 20 Nov, 2017 1 commit
  4. 18 Nov, 2017 2 commits
  5. 17 Nov, 2017 6 commits
  6. 16 Nov, 2017 3 commits
  7. 14 Nov, 2017 1 commit
  8. 10 Nov, 2017 1 commit
  9. 09 Nov, 2017 3 commits
    • Teng Qin's avatar
      73e2f2d7
    • Yonghong Song's avatar
      change frontend rewriter to better handle anonymous struct/union · 94d15bc8
      Yonghong Song authored
      Kernel Commit 29e48ce87f1e ("task_struct: Allow randomized layout")
      (https://patchwork.kernel.org/patch/9797817/)
      permits to randomize a section of kernel task_struct data
      structure. This only takes effect when CONFIG_GCC_PLUGINS and
      CONFIG_GCC_PLUGIN_RANDSTRUCT are set.
      
      When randomization does not happen, an anonymous struct
      is introduced in task_struct data structure by gcc when compiling
      the kernel. To make field offset compatible, task_struct will
      have the same anonymous struct. The patch is at
      http://www.spinics.net/lists/kernel/msg2644958.html.
      Otherwise, bpf program may get wrong data from the kernel.
      
      Currently, bcc bpf_probe_read rewriter does not support
      anonymous struct/union. For example, with the above
      compiler-clang.h patch, examples/tracing/task_switch.py
      will have the following error:
        /virtual/main.c:16:18: error: internal error: opLoc is invalid while preparing probe rewrite
          key.prev_pid = prev->pid;
                         ^
      
      For anonymous structure, opcode source location ("->") is not available
      and hence the above failure. We could use memberLoc ("pid") which is
      available for anonymous struct/union. For example, for
        struct sock *skp; ...; u32 saddr = skp->__sk_common.skc_rcv_saddr;
      The old way for bpf_probe_read rewrite:
        bpf_probe_read(&_val, sizeof(_val), (u64)skp + offsetof(struct sock, __sk_common.skc_rcv_saddr));
      The new way:
        bpf_probe_read(&_val, sizeof(_val), (u64)&skp->__sk_common.skc_rcv_saddr);
      
      The new way is similar to what typical bpf programs may do manually.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      94d15bc8
    • Gary Lin's avatar
      bpf: use MCJIT explicitly for ExecutionEngine · 1d0f2925
      Gary Lin authored
      When BPFModule finalized the module, it set UseOrcMCJITReplacement to
      true to use OrcJIT for ExecutionEngine. However, this never worked.
      First, in clang_libs.cmake, mcjit is in the library list instead of
      orcjit, so ExecutionEngine always fell back to MCJIT.
      Second, even if OrcJIT was linked correctly, it actually broke bcc.
      For OrcJIT, finalizeObject() is just an empty function. The code
      generation is delayed till getPointerToFunction() or runFunction(), so
      the current implementation of BPFModule won't work for OrcJIT.
      
      This bug was covered when using the separate LLVM share libraries. If
      the system builds LLVM into an unified share library, then OrcJIT will
      be used and bcc would fail to generate BPF bytecodes without any
      warning.
      Signed-off-by: default avatarGary Lin <glin@suse.com>
      1d0f2925
  10. 08 Nov, 2017 6 commits
  11. 06 Nov, 2017 1 commit
  12. 04 Nov, 2017 1 commit
    • Yonghong Song's avatar
      fix clang frontend issues for fc26 · 6fc8d15c
      Yonghong Song authored
      In fc26, kernel config enables CONFIG_FORTIFY_SOURCE
      in 4.13 kernel. This is not available in fc25.
      This config is used to detect overflows of buffers in common string
      and memory functions where the compiler can determine and
      validate the buffer sizes.
      
      When enabled, this option provides an implementation (body)
      for certain string function. For example, in
      /lib/modules/4.13.10-200.fc26.x86_64/build/include/linux/string.h,
      you can find
      ...
      extern void * memcpy(void *,const void *,__kernel_size_t);
      ...
      __FORTIFY_INLINE void *memcpy(void *p, const void *q, __kernel_size_t size)
      {
              size_t p_size = __builtin_object_size(p, 0);
              size_t q_size = __builtin_object_size(q, 0);
              if (__builtin_constant_p(size)) {
                      if (p_size < size)
                              __write_overflow();
                      if (q_size < size)
                              __read_overflow2();
              }
              if (p_size < size || q_size < size)
                      fortify_panic(__func__);
              return __builtin_memcpy(p, q, size);
      }
      
      In current clang frontend, we treat an external function with function body
      as a rewritable target. We also assume the declaration of this external function,
      if body is present, must have named arguments. This is largely true
      for functions in bpf program file/text itself as these external functions often
      do not have declarations.
      
      We should not try to rewrite string/memory functions exposed by
      CONFIG_FORTIFY_SOURCE. This patch adds restriction for rewritable function
      only if the corresponding file is the main file with bpf program itself.
      
      I discovered that it is possible file name is empty for tracepoint
      functions, e.g.,
        TRACEPOINT_PROBE(irq, softirq_entry)
      The reason could be function name itself is derived from helpers.h while
      function declaration/body is in the main file after macro expansion.
      Note that function name is still correctly derived by the compiler.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      6fc8d15c
  13. 02 Nov, 2017 1 commit
  14. 01 Nov, 2017 4 commits
  15. 31 Oct, 2017 1 commit
  16. 29 Oct, 2017 1 commit
  17. 28 Oct, 2017 1 commit
  18. 27 Oct, 2017 1 commit