1. 06 Dec, 2018 2 commits
    • Martin KaFai Lau's avatar
      bpf: Change insn_offset to insn_off in bpf_func_info · d30d42e0
      Martin KaFai Lau authored
      The later patch will introduce "struct bpf_line_info" which
      has member "line_off" and "file_off" referring back to the
      string section in btf.  The line_"off" and file_"off"
      are more consistent to the naming convention in btf.h that
      means "offset" (e.g. name_off in "struct btf_type").
      
      The to-be-added "struct bpf_line_info" also has another
      member, "insn_off" which is the same as the "insn_offset"
      in "struct bpf_func_info".  Hence, this patch renames "insn_offset"
      to "insn_off" for "struct bpf_func_info".
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d30d42e0
    • Martin KaFai Lau's avatar
      bpf: Improve the info.func_info and info.func_info_rec_size behavior · 7337224f
      Martin KaFai Lau authored
      1) When bpf_dump_raw_ok() == false and the kernel can provide >=1
         func_info to the userspace, the current behavior is setting
         the info.func_info_cnt to 0 instead of setting info.func_info
         to 0.
      
         It is different from the behavior in jited_func_lens/nr_jited_func_lens,
         jited_ksyms/nr_jited_ksyms...etc.
      
         This patch fixes it. (i.e. set func_info to 0 instead of
         func_info_cnt to 0 when bpf_dump_raw_ok() == false).
      
      2) When the userspace passed in info.func_info_cnt == 0, the kernel
         will set the expected func_info size back to the
         info.func_info_rec_size.  It is a way for the userspace to learn
         the kernel expected func_info_rec_size introduced in
         commit 838e9690 ("bpf: Introduce bpf_func_info").
      
         An exception is the kernel expected size is not set when
         func_info is not available for a bpf_prog.  This makes the
         returned info.func_info_rec_size has different values
         depending on the returned value of info.func_info_cnt.
      
         This patch sets the kernel expected size to info.func_info_rec_size
         independent of the info.func_info_cnt.
      
      3) The current logic only rejects invalid func_info_rec_size if
         func_info_cnt is non zero.  This patch also rejects invalid
         nonzero info.func_info_rec_size and not equal to the kernel
         expected size.
      
      4) Set info.btf_id as long as prog->aux->btf != NULL.  That will
         setup the later copy_to_user() codes look the same as others
         which then easier to understand and maintain.
      
         prog->aux->btf is not NULL only if prog->aux->func_info_cnt > 0.
      
         Breaking up info.btf_id from prog->aux->func_info_cnt is needed
         for the later line info patch anyway.
      
         A similar change is made to bpf_get_prog_name().
      
      Fixes: 838e9690 ("bpf: Introduce bpf_func_info")
      Signed-off-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      7337224f
  2. 05 Dec, 2018 4 commits
    • Quentin Monnet's avatar
      tools: bpftool: add a command to dump the trace pipe · 30da46b5
      Quentin Monnet authored
      BPF programs can use the bpf_trace_printk() helper to print debug
      information into the trace pipe. Add a subcommand
      "bpftool prog tracelog" to simply dump this pipe to the console.
      
      This is for a good part copied from iproute2, where the feature is
      available with "tc exec bpf dbg". Changes include dumping pipe content
      to stdout instead of stderr and adding JSON support (content is dumped
      as an array of strings, one per line read from the pipe). This version
      is dual-licensed, with Daniel's permission.
      
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Suggested-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Signed-off-by: default avatarQuentin Monnet <quentin.monnet@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      30da46b5
    • Daniel Borkmann's avatar
      Merge branch 'bpf-jit-overridable-alloc' · 41888179
      Daniel Borkmann authored
      Ard Biesheuvel says:
      
      ====================
      On arm64, modules are allocated from a 128 MB window which is close to
      the core kernel, so that relative direct branches are guaranteed to be
      in range (except in some KASLR configurations). Also, module_alloc()
      is in charge of allocating KASAN shadow memory when running with KASAN
      enabled.
      
      This means that the way BPF reuses module_alloc()/module_memfree() is
      undesirable on arm64 (and potentially other architectures as well),
      and so this series refactors BPF's use of those functions to permit
      architectures to change this behavior.
      
      Patch #1 breaks out the module_alloc() and module_memfree() calls into
      __weak functions so they can be overridden.
      
      Patch #2 implements the new alloc/free overrides for arm64
      
      Changes since v3:
      - drop 'const' modifier for free() hook void* argument
      - move the dedicated BPF region to before the module region, putting it
        within 4GB of the module and kernel regions on non-KASLR kernels
      
      Changes since v2:
      - properly build time and runtime tested this time (log after the diffstat)
      - create a dedicated 128 MB region at the top of the vmalloc space for BPF
        programs, ensuring that the programs will be in branching range of each
        other (which we currently rely upon) but at an arbitrary distance from
        the kernel and modules (which we don't care about)
      
      Changes since v1:
      - Drop misguided attempt to 'fix' and refactor the free path. Instead,
        just add another __weak wrapper for the invocation of module_memfree()
      ====================
      
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Rick Edgecombe <rick.p.edgecombe@intel.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Jann Horn <jannh@google.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-kernel@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      41888179
    • Ard Biesheuvel's avatar
      arm64/bpf: don't allocate BPF JIT programs in module memory · 91fc957c
      Ard Biesheuvel authored
      The arm64 module region is a 128 MB region that is kept close to
      the core kernel, in order to ensure that relative branches are
      always in range. So using the same region for programs that do
      not have this restriction is wasteful, and preferably avoided.
      
      Now that the core BPF JIT code permits the alloc/free routines to
      be overridden, implement them by vmalloc()/vfree() calls from a
      dedicated 128 MB region set aside for BPF programs. This ensures
      that BPF programs are still in branching range of each other, which
      is something the JIT currently depends upon (and is not guaranteed
      when using module_alloc() on KASLR kernels like we do currently).
      It also ensures that placement of BPF programs does not correlate
      with the placement of the core kernel or modules, making it less
      likely that leaking the former will reveal the latter.
      
      This also solves an issue under KASAN, where shadow memory is
      needlessly allocated for all BPF programs (which don't require KASAN
      shadow pages since they are not KASAN instrumented)
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      91fc957c
    • Ard Biesheuvel's avatar
      bpf: add __weak hook for allocating executable memory · dc002bb6
      Ard Biesheuvel authored
      By default, BPF uses module_alloc() to allocate executable memory,
      but this is not necessary on all arches and potentially undesirable
      on some of them.
      
      So break out the module_alloc() and module_memfree() calls into __weak
      functions to allow them to be overridden in arch code.
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      dc002bb6
  3. 04 Dec, 2018 5 commits
  4. 03 Dec, 2018 4 commits
  5. 02 Dec, 2018 1 commit
  6. 01 Dec, 2018 9 commits
    • Alexei Starovoitov's avatar
      Merge branch 'xdp1-improvements' · 71fc156f
      Alexei Starovoitov authored
      Matteo Croce says:
      
      ====================
      Small improvements to improve the readability and easiness
      to use of the xdp1 sample.
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      71fc156f
    • Matteo Croce's avatar
      samples: bpf: get ifindex from ifname · dc378a1a
      Matteo Croce authored
      Find the ifindex with if_nametoindex() instead of requiring the
      numeric ifindex.
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      dc378a1a
    • Matteo Croce's avatar
      samples: bpf: improve xdp1 example · d606ee5c
      Matteo Croce authored
      Store only the total packet count for every protocol, instead of the
      whole per-cpu array.
      Use bpf_map_get_next_key() to iterate the map, instead of looking up
      all the protocols.
      Signed-off-by: default avatarMatteo Croce <mcroce@redhat.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d606ee5c
    • Alexei Starovoitov's avatar
      Merge branch 'improve-test-coverage-sparc' · 9ffd05d9
      Alexei Starovoitov authored
      David Miller says:
      
      ====================
      On sparc64 a ton of test cases in test_verifier.c fail because
      the memory accesses in the test case are unaligned (or cannot
      be proven to be aligned by the verifier).
      
      Perhaps we can eventually try to (carefully) modify each test case
      which has this problem to not use unaligned accesses but:
      
      1) That is delicate work.
      
      2) The changes might not fully respect the original
         intention of the testcase.
      
      3) In some cases, such a transformation might not even
         be feasible at all.
      
      So add an "any alignment" flag to tell the verifier to forcefully
      disable it's alignment checks completely.
      
      test_verifier.c is then annotated to use this flag when necessary.
      
      The presence of the flag in each test case is good documentation to
      anyone who wants to actually tackle the job of eliminating the
      unaligned memory accesses in the test cases.
      
      I've also seen several weird things in test cases, like trying to
      access __skb->mark in a packet buffer.
      
      This gets rid of 104 test_verifier.c failures on sparc64.
      
      Changes since v1:
      
      1) Explain the new BPF_PROG_LOAD flag in easier to understand terms.
         Suggested by Alexei.
      
      2) Make bpf_verify_program() just take a __u32 prog_flags instead of
         just accumulating boolean arguments over and over.  Also suggested
         by Alexei.
      
      Changes since RFC:
      
      1) Only the admin can allow the relaxation of alignment restrictions
         on inefficient unaligned access architectures.
      
      2) Use F_NEEDS_EFFICIENT_UNALIGNED_ACCESS instead of making a new
         flag.
      
      3) Annotate in the output, when we have a test case that the verifier
         accepted but we did not try to execute because we are on an
         inefficient unaligned access platform.  Maybe with some arch
         machinery we can avoid this in the future.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      9ffd05d9
    • David Miller's avatar
      bpf: Apply F_NEEDS_EFFICIENT_UNALIGNED_ACCESS to more ACCEPT test cases. · 0a686324
      David Miller authored
      If a testcase has alignment problems but is expected to be ACCEPT,
      verify it using F_NEEDS_EFFICIENT_UNALIGNED_ACCESS too.
      
      Maybe in the future if we add some architecture specific code to elide
      the unaligned memory access warnings during the test, we can execute
      these as well.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      0a686324
    • David Miller's avatar
      bpf: Make more use of 'any' alignment in test_verifier.c · 2acc5fd5
      David Miller authored
      Use F_NEEDS_EFFICIENT_UNALIGNED_ACCESS in more tests where the
      expected result is REJECT.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      2acc5fd5
    • David Miller's avatar
      bpf: Adjust F_NEEDS_EFFICIENT_UNALIGNED_ACCESS handling in test_verifier.c · c7665702
      David Miller authored
      Make it set the flag argument to bpf_verify_program() which will relax
      the alignment restrictions.
      
      Now all such test cases will go properly through the verifier even on
      inefficient unaligned access architectures.
      
      On inefficient unaligned access architectures do not try to run such
      programs, instead mark the test case as passing but annotate the
      result similarly to how it is done now in the presence of this flag.
      
      So, we get complete full coverage for all REJECT test cases, and at
      least verifier level coverage for ACCEPT test cases.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      c7665702
    • David Miller's avatar
      bpf: Add BPF_F_ANY_ALIGNMENT. · e9ee9efc
      David Miller authored
      Often we want to write tests cases that check things like bad context
      offset accesses.  And one way to do this is to use an odd offset on,
      for example, a 32-bit load.
      
      This unfortunately triggers the alignment checks first on platforms
      that do not set CONFIG_EFFICIENT_UNALIGNED_ACCESS.  So the test
      case see the alignment failure rather than what it was testing for.
      
      It is often not completely possible to respect the original intention
      of the test, or even test the same exact thing, while solving the
      alignment issue.
      
      Another option could have been to check the alignment after the
      context and other validations are performed by the verifier, but
      that is a non-trivial change to the verifier.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      e9ee9efc
    • David Miller's avatar
      bpf: Fix verifier log string check for bad alignment. · 88945f46
      David Miller authored
      The message got changed a lot time ago.
      
      This was responsible for 36 test case failures on sparc64.
      
      Fixes: f1174f77 ("bpf/verifier: rework value tracking")
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      88945f46
  7. 30 Nov, 2018 10 commits
  8. 29 Nov, 2018 5 commits