1. 13 Jun, 2018 2 commits
    • yonghong-song's avatar
      generate indirect parameter assignment if arch uses syscall wrapper (#1816) · 2da34267
      yonghong-song authored
      Fix issue #1802.
      
      On x64, the following commit (in 4.17) changed the raw parameter passed to
      the syscall entry function from a list of parameters supplied in user space
      to a single `pt_regs *` parameter. Also in 4.17, x64 syscall entry function
      is changed from `sys_<name>` to `__x64_sys_<name>`.
      
      ```
      commit fa697140f9a20119a9ec8fd7460cc4314fbdaff3
      Author: Dominik Brodowski <linux@dominikbrodowski.net>
      Date:   Thu Apr 5 11:53:02 2018 +0200
      
          syscalls/x86: Use 'struct pt_regs' based syscall calling convention for 64-bit syscalls
      
          Let's make use of ARCH_HAS_SYSCALL_WRAPPER=y on pure 64-bit x86-64 systems:
      
          Each syscall defines a stub which takes struct pt_regs as its only
          argument. It decodes just those parameters it needs, e.g:
      
                  asmlinkage long sys_xyzzy(const struct pt_regs *regs)
                  {
                          return SyS_xyzzy(regs->di, regs->si, regs->dx);
                  }
      
          This approach avoids leaking random user-provided register content down
          the call chain.
      
          ...
      ```
      
      In bcc, we support kprobe function signatures in the bpf program.
      The rewriter will automatically generate proper assignment to
      these parameters. With the above function signature change, the
      original method does not work any more.
      
      This patch enhanced rewriter to generate two version codes guarded
      with CONFIG_ARCH_HAS_SYSCALL_WRAPPER. But we need to identify
      whether a function will be attached to syscall entry function
      or not during prog load time at which time the program has not
      attached to any event.
      
      The prefix `kprobe__` is used for kprobe autoload, we can use
      `kprobe____x64_sys_` as the prefix to identify x64 syscall entry
      functions. To support other architecture or not-autoloading program,
      the prefix `syscall__` is introduced to signal it is a syscall
      entry function.
      
      trace.py and other tools which uses kprobe syscall entry functions
      are also modified with the new interface so that they can
      work properly with 4.17.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      2da34267
    • Paul Chaignon's avatar
      Fix 20fb64cd and skip probe rewriter for bpf_probe_read (#1812) · eebd4856
      Paul Chaignon authored
      20fb64cd stops the whole AST traversal if it meets a bpf_probe_read call.  I
      think the original intent was to simply not rewrite the third argument, so this
      commit fixes it by remembering the third argument on bpf_probe_read call
      traversals and overriding TraverseStmt to skip the traversal of that argument
      when we meet it later.
      eebd4856
  2. 11 Jun, 2018 10 commits
  3. 10 Jun, 2018 1 commit
    • Yonghong Song's avatar
      adjust tracepoint field type based on size · 7c489469
      Yonghong Song authored
      Fix issue #1807
      
      tracepoint may have a format like this:
      (from syscalls/sys_enter_socket)
      	field:unsigned short common_type;	offset:0;	size:2;	signed:0;
      	field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
      	field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
      	field:int common_pid;	offset:4;	size:4;	signed:1;
      
      	field:int __syscall_nr;	offset:8;	size:4;	signed:1;
      	field:int family;	offset:16;	size:8;	signed:0;
      	field:int type;	offset:24;	size:8;	signed:0;
      	field:int protocol;	offset:32;	size:8;	signed:0;
      
      Current rewriter generates:
          struct tracepoint__syscalls__sys_enter_socket {
      	    u64 __do_not_use__;
      	    int __syscall_nr;
      	    int family;
      	    int type;
      	    int protocol;
          };
      
      This is incorrect as in the above structure, offsets of
      `family`/`type`/`procotol` becomingg 12/16/20.
      
      This patch fixed the issue by adjusting field type based on its size.
      The new structure:
          struct tracepoint__syscalls__sys_enter_socket {
      	    u64 __do_not_use__;
      	    int __syscall_nr;
      	    s64 family;
      	    s64 type;
      	    s64 protocol;
          };
      The offsets of all fields are correct now.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      7c489469
  4. 08 Jun, 2018 8 commits
  5. 07 Jun, 2018 1 commit
  6. 06 Jun, 2018 5 commits
  7. 05 Jun, 2018 4 commits
  8. 03 Jun, 2018 1 commit
  9. 02 Jun, 2018 5 commits
    • Yonghong Song's avatar
      skip probe rewriter for bpf_probe_read() · 20fb64cd
      Yonghong Song authored
      bpf_probe_read() is often used to access pointees in bpf programs.
      Recent rewriter has become smarter so a lot of bpf_probe_read()
      can be replaced with simple pointer/member access.
      
      In certain cases, bpf_probe_read() is still preferred though.
      For example, kernel net/tcp.h defined TCP_SKB_CB as below
        #define TCP_SKB_CB(__skb)	((struct tcp_skb_cb *)&((__skb)->cb[0]))
      User can use below to access tcp_gso_size of a skb data structure.
        TCP_SKB_CB(skb)->tcp_gso_size
      The rewriter will fail as it attempts to rewrite (__skb)->cb[0].
      
      Instead of chasing down to prevent exactly the above pattern,
      this patch detects function bpf_probe_read() in ProbeVisitor and
      will skip it so bpf_probe_read()'s third parameter is a AddrOf.
      This can also help other cases where rewriter is not
      capable and user used bpf_probe_read() as the workaround.
      
      Also fixed tcptop.py to use direct assignment instead of
      bpf_probe_read. Otherwise, rewriter will actually rewrite
      src address reference inside the bpf_probe_read().
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      20fb64cd
    • 4ast's avatar
      Merge pull request #1795 from iovisor/yhs_dev2 · db093366
      4ast authored
      Add "-D __BPF_TRACING__" to frontend compilation flags
      db093366
    • Yonghong Song's avatar
      Add "-D __BPF_TRACING__" to frontend compilation flags · 7c4311f6
      Yonghong Song authored
      In 4.17 kernel, x86 build requires compiler asm-goto support. clang
      does not support asm-goto and bpf program compilation started to break.
      The following kernel commit
      
        commit b1ae32dbab50ed19cfc16d225b0fb0114fb13025
        Author: Alexei Starovoitov <ast@kernel.org>
        Date:   Sun May 13 12:32:22 2018 -0700
      
            x86/cpufeature: Guard asm_volatile_goto usage for BPF compilation
      
            Workaround for the sake of BPF compilation which utilizes kernel
            headers, but clang does not support ASM GOTO and fails the build.
      
      workarounded the issue by permitting native clang compilation.
      A warning message, however, is issued:
      
        ./arch/x86/include/asm/cpufeature.h:150:2: warning: "Compiler lacks ASM_GOTO support.
              Add -D __BPF_TRACING__ to your compiler arguments" [-W#warnings]
        #warning "Compiler lacks ASM_GOTO support. Add -D __BPF_TRACING__ to your compil...
         ^
        1 warning generated.
      
      This patch added "-D __BPF_TRACING__" to clang frontend compilation to
      suppress the warning.
      Signed-off-by: default avatarYonghong Song <yhs@fb.com>
      7c4311f6
    • yonghong-song's avatar
      Merge pull request #1792 from pchaigno/refactor-ext-ptr-assignments · d8bb097d
      yonghong-song authored
      Refactor external pointer assignments
      d8bb097d
    • yonghong-song's avatar
      Merge pull request #1793 from qmonnet/kernelfeatures · c817cfd6
      yonghong-song authored
      sync BPF compat headers with latest bpf-next, update BPF features list
      c817cfd6
  10. 01 Jun, 2018 3 commits