1. 30 5月, 2019 8 次提交
  2. 28 5月, 2019 2 次提交
  3. 25 5月, 2019 1 次提交
  4. 17 5月, 2019 1 次提交
  5. 16 5月, 2019 1 次提交
  6. 13 5月, 2019 1 次提交
    • A
      libbpf: detect supported kernel BTF features and sanitize BTF · d7c4b398
      Andrii Nakryiko 提交于
      Depending on used versions of libbpf, Clang, and kernel, it's possible to
      have valid BPF object files with valid BTF information, that still won't
      load successfully due to Clang emitting newer BTF features (e.g.,
      BTF_KIND_FUNC, .BTF.ext's line_info/func_info, BTF_KIND_DATASEC, etc), that
      are not yet supported by older kernel.
      
      This patch adds detection of BTF features and sanitizes BPF object's BTF
      by substituting various supported BTF kinds, which have compatible layout:
        - BTF_KIND_FUNC -> BTF_KIND_TYPEDEF
        - BTF_KIND_FUNC_PROTO -> BTF_KIND_ENUM
        - BTF_KIND_VAR -> BTF_KIND_INT
        - BTF_KIND_DATASEC -> BTF_KIND_STRUCT
      
      Replacement is done in such a way as to preserve as much information as
      possible (names, sizes, etc) where possible without violating kernel's
      validation rules.
      
      v2->v3:
        - remove duplicate #defines from libbpf_util.h
      
      v1->v2:
        - add internal libbpf_internal.h w/ common stuff
        - switch SK storage BTF to use new libbpf__probe_raw_btf()
      Reported-by: NAlexei Starovoitov <ast@fb.com>
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      d7c4b398
  7. 27 4月, 2019 1 次提交
  8. 26 4月, 2019 2 次提交
  9. 17 4月, 2019 1 次提交
  10. 13 4月, 2019 1 次提交
  11. 11 4月, 2019 1 次提交
    • A
      libbpf: Fix build with gcc-8 · d5adbdd7
      Andrey Ignatov 提交于
      Reported in [1].
      
      With gcc 8.3.0 the following error is issued:
      
        cc -Ibpf@sta -I. -I.. -I.././include -I.././include/uapi
        -fdiagnostics-color=always -fsanitize=address,undefined -fno-omit-frame-pointer
        -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Werror -g -fPIC -g -O2
        -Werror -Wall -Wno-pointer-arith -Wno-sign-compare  -MD -MQ
        'bpf@sta/src_libbpf.c.o' -MF 'bpf@sta/src_libbpf.c.o.d' -o
        'bpf@sta/src_libbpf.c.o' -c ../src/libbpf.c
        ../src/libbpf.c: In function 'bpf_object__elf_collect':
        ../src/libbpf.c:947:18: error: 'map_def_sz' may be used uninitialized in this
        function [-Werror=maybe-uninitialized]
           if (map_def_sz <= sizeof(struct bpf_map_def)) {
               ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        ../src/libbpf.c:827:18: note: 'map_def_sz' was declared here
          int i, map_idx, map_def_sz, nr_syms, nr_maps = 0, nr_maps_glob = 0;
                          ^~~~~~~~~~
      
      According to [2] -Wmaybe-uninitialized is enabled by -Wall.
      Same error is generated by clang's -Wconditional-uninitialized.
      
      [1] https://github.com/libbpf/libbpf/pull/29#issuecomment-481902601
      [2] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
      
      Fixes: d859900c ("bpf, libbpf: support global data/bss/rodata sections")
      Reported-by: NEvgeny Vereshchagin <evvers@ya.ru>
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      d5adbdd7
  12. 10 4月, 2019 3 次提交
    • D
      bpf, libbpf: add support for BTF Var and DataSec · 1713d68b
      Daniel Borkmann 提交于
      This adds libbpf support for BTF Var and DataSec kinds. Main point
      here is that libbpf needs to do some preparatory work before the
      whole BTF object can be loaded into the kernel, that is, fixing up
      of DataSec size taken from the ELF section size and non-static
      variable offset which needs to be taken from the ELF's string section.
      
      Upstream LLVM doesn't fix these up since at time of BTF emission
      it is too early in the compilation process thus this information
      isn't available yet, hence loader needs to take care of it.
      
      Note, deduplication handling has not been in the scope of this work
      and needs to be addressed in a future commit.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Link: https://reviews.llvm.org/D59441Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      1713d68b
    • D
      bpf, libbpf: support global data/bss/rodata sections · d859900c
      Daniel Borkmann 提交于
      This work adds BPF loader support for global data sections
      to libbpf. This allows to write BPF programs in more natural
      C-like way by being able to define global variables and const
      data.
      
      Back at LPC 2018 [0] we presented a first prototype which
      implemented support for global data sections by extending BPF
      syscall where union bpf_attr would get additional memory/size
      pair for each section passed during prog load in order to later
      add this base address into the ldimm64 instruction along with
      the user provided offset when accessing a variable. Consensus
      from LPC was that for proper upstream support, it would be
      more desirable to use maps instead of bpf_attr extension as
      this would allow for introspection of these sections as well
      as potential live updates of their content. This work follows
      this path by taking the following steps from loader side:
      
       1) In bpf_object__elf_collect() step we pick up ".data",
          ".rodata", and ".bss" section information.
      
       2) If present, in bpf_object__init_internal_map() we add
          maps to the obj's map array that corresponds to each
          of the present sections. Given section size and access
          properties can differ, a single entry array map is
          created with value size that is corresponding to the
          ELF section size of .data, .bss or .rodata. These
          internal maps are integrated into the normal map
          handling of libbpf such that when user traverses all
          obj maps, they can be differentiated from user-created
          ones via bpf_map__is_internal(). In later steps when
          we actually create these maps in the kernel via
          bpf_object__create_maps(), then for .data and .rodata
          sections their content is copied into the map through
          bpf_map_update_elem(). For .bss this is not necessary
          since array map is already zero-initialized by default.
          Additionally, for .rodata the map is frozen as read-only
          after setup, such that neither from program nor syscall
          side writes would be possible.
      
       3) In bpf_program__collect_reloc() step, we record the
          corresponding map, insn index, and relocation type for
          the global data.
      
       4) And last but not least in the actual relocation step in
          bpf_program__relocate(), we mark the ldimm64 instruction
          with src_reg = BPF_PSEUDO_MAP_VALUE where in the first
          imm field the map's file descriptor is stored as similarly
          done as in BPF_PSEUDO_MAP_FD, and in the second imm field
          (as ldimm64 is 2-insn wide) we store the access offset
          into the section. Given these maps have only single element
          ldimm64's off remains zero in both parts.
      
       5) On kernel side, this special marked BPF_PSEUDO_MAP_VALUE
          load will then store the actual target address in order
          to have a 'map-lookup'-free access. That is, the actual
          map value base address + offset. The destination register
          in the verifier will then be marked as PTR_TO_MAP_VALUE,
          containing the fixed offset as reg->off and backing BPF
          map as reg->map_ptr. Meaning, it's treated as any other
          normal map value from verification side, only with
          efficient, direct value access instead of actual call to
          map lookup helper as in the typical case.
      
      Currently, only support for static global variables has been
      added, and libbpf rejects non-static global variables from
      loading. This can be lifted until we have proper semantics
      for how BPF will treat multi-object BPF loads. From BTF side,
      libbpf will set the value type id of the types corresponding
      to the ".bss", ".data" and ".rodata" names which LLVM will
      emit without the object name prefix. The key type will be
      left as zero, thus making use of the key-less BTF option in
      array maps.
      
      Simple example dump of program using globals vars in each
      section:
      
        # bpftool prog
        [...]
        6784: sched_cls  name load_static_dat  tag a7e1291567277844  gpl
              loaded_at 2019-03-11T15:39:34+0000  uid 0
              xlated 1776B  jited 993B  memlock 4096B  map_ids 2238,2237,2235,2236,2239,2240
      
        # bpftool map show id 2237
        2237: array  name test_glo.bss  flags 0x0
              key 4B  value 64B  max_entries 1  memlock 4096B
        # bpftool map show id 2235
        2235: array  name test_glo.data  flags 0x0
              key 4B  value 64B  max_entries 1  memlock 4096B
        # bpftool map show id 2236
        2236: array  name test_glo.rodata  flags 0x80
              key 4B  value 96B  max_entries 1  memlock 4096B
      
        # bpftool prog dump xlated id 6784
        int load_static_data(struct __sk_buff * skb):
        ; int load_static_data(struct __sk_buff *skb)
           0: (b7) r6 = 0
        ; test_reloc(number, 0, &num0);
           1: (63) *(u32 *)(r10 -4) = r6
           2: (bf) r2 = r10
        ; int load_static_data(struct __sk_buff *skb)
           3: (07) r2 += -4
        ; test_reloc(number, 0, &num0);
           4: (18) r1 = map[id:2238]
           6: (18) r3 = map[id:2237][0]+0    <-- direct addr in .bss area
           8: (b7) r4 = 0
           9: (85) call array_map_update_elem#100464
          10: (b7) r1 = 1
        ; test_reloc(number, 1, &num1);
        [...]
        ; test_reloc(string, 2, str2);
         120: (18) r8 = map[id:2237][0]+16   <-- same here at offset +16
         122: (18) r1 = map[id:2239]
         124: (18) r3 = map[id:2237][0]+16
         126: (b7) r4 = 0
         127: (85) call array_map_update_elem#100464
         128: (b7) r1 = 120
        ; str1[5] = 'x';
         129: (73) *(u8 *)(r9 +5) = r1
        ; test_reloc(string, 3, str1);
         130: (b7) r1 = 3
         131: (63) *(u32 *)(r10 -4) = r1
         132: (b7) r9 = 3
         133: (bf) r2 = r10
        ; int load_static_data(struct __sk_buff *skb)
         134: (07) r2 += -4
        ; test_reloc(string, 3, str1);
         135: (18) r1 = map[id:2239]
         137: (18) r3 = map[id:2235][0]+16   <-- direct addr in .data area
         139: (b7) r4 = 0
         140: (85) call array_map_update_elem#100464
         141: (b7) r1 = 111
        ; __builtin_memcpy(&str2[2], "hello", sizeof("hello"));
         142: (73) *(u8 *)(r8 +6) = r1       <-- further access based on .bss data
         143: (b7) r1 = 108
         144: (73) *(u8 *)(r8 +5) = r1
        [...]
      
      For Cilium use-case in particular, this enables migrating configuration
      constants from Cilium daemon's generated header defines into global
      data sections such that expensive runtime recompilations with LLVM can
      be avoided altogether. Instead, the ELF file becomes effectively a
      "template", meaning, it is compiled only once (!) and the Cilium daemon
      will then rewrite relevant configuration data from the ELF's .data or
      .rodata sections directly instead of recompiling the program. The
      updated ELF is then loaded into the kernel and atomically replaces
      the existing program in the networking datapath. More info in [0].
      
      Based upon recent fix in LLVM, commit c0db6b6bd444 ("[BPF] Don't fail
      for static variables").
      
        [0] LPC 2018, BPF track, "ELF relocation for static data in BPF",
            http://vger.kernel.org/lpc-bpf2018.html#session-3Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      d859900c
    • J
      bpf, libbpf: refactor relocation handling · f8c7a4d4
      Joe Stringer 提交于
      Adjust the code for relocations slightly with no functional changes,
      so that upcoming patches that will introduce support for relocations
      into the .data, .rodata and .bss sections can be added independent
      of these changes.
      Signed-off-by: NJoe Stringer <joe@wand.net.nz>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      f8c7a4d4
  13. 07 4月, 2019 1 次提交
  14. 04 4月, 2019 1 次提交
    • A
      libbpf: teach libbpf about log_level bit 2 · da11b417
      Alexei Starovoitov 提交于
      Allow bpf_prog_load_xattr() to specify log_level for program loading.
      
      Teach libbpf to accept log_level with bit 2 set.
      
      Increase default BPF_LOG_BUF_SIZE from 256k to 16M.
      There is no downside to increase it to a maximum allowed by old kernels.
      Existing 256k limit caused ENOSPC errors and users were not able to see
      verifier error which is printed at the end of the verifier log.
      
      If ENOSPC is hit, double the verifier log and try again to capture
      the verifier error.
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      da11b417
  15. 20 3月, 2019 2 次提交
  16. 11 3月, 2019 1 次提交
  17. 09 3月, 2019 1 次提交
  18. 01 3月, 2019 1 次提交
  19. 15 2月, 2019 3 次提交
    • A
      libbpf: Introduce bpf_object__btf · 789f6bab
      Andrey Ignatov 提交于
      Add new accessor for bpf_object to get opaque struct btf * from it.
      
      struct btf * is needed for all operations with BTF and it's present in
      bpf_object. The only thing missing is a way to get it.
      
      Example use-case is to get BTF key_type_id and value_type_id for a map in
      bpf_object. It can be done with btf__get_map_kv_tids() but that function
      requires struct btf *.
      
      Similar API can be added for struct btf_ext but no use-case for it yet.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      789f6bab
    • A
      libbpf: Introduce bpf_map__resize · 1a11a4c7
      Andrey Ignatov 提交于
      Add bpf_map__resize() to change max_entries for a map.
      
      Quite often necessary map size is unknown at compile time and can be
      calculated only at run time.
      
      Currently the following approach is used to do so:
      * bpf_object__open_buffer() to open Elf file from a buffer;
      * bpf_object__find_map_by_name() to find relevant map;
      * bpf_map__def() to get map attributes and create struct
        bpf_create_map_attr from them;
      * update max_entries in bpf_create_map_attr;
      * bpf_create_map_xattr() to create new map with updated max_entries;
      * bpf_map__reuse_fd() to replace the map in bpf_object with newly
        created one.
      
      And after all this bpf_object can finally be loaded. The map will have
      new size.
      
      It 1) is quite a lot of steps; 2) doesn't take BTF into account.
      
      For "2)" even more steps should be made and some of them require changes
      to libbpf (e.g. to get struct btf * from bpf_object).
      
      Instead the whole problem can be solved by introducing simple
      bpf_map__resize() API that checks the map and sets new max_entries if
      the map is not loaded yet.
      
      So the new steps are:
      * bpf_object__open_buffer() to open Elf file from a buffer;
      * bpf_object__find_map_by_name() to find relevant map;
      * bpf_map__resize() to update max_entries.
      
      That's much simpler and works with BTF.
      Signed-off-by: NAndrey Ignatov <rdna@fb.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      1a11a4c7
    • A
      tools/bpf: replace bzero with memset · 1ad9cbb8
      Andrii Nakryiko 提交于
      bzero() call is deprecated and superseded by memset().
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Reported-by: NDavid Laight <david.laight@aculab.com>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      1ad9cbb8
  20. 09 2月, 2019 1 次提交
    • A
      btf: separate btf creation and loading · d29d87f7
      Andrii Nakryiko 提交于
      This change splits out previous btf__new functionality of constructing
      struct btf and loading it into kernel into two:
      - btf__new() just creates and initializes struct btf
      - btf__load() attempts to load existing struct btf into kernel
      
      btf__free will still close BTF fd, if it was ever loaded successfully
      into kernel.
      
      This change allows users of libbpf to manipulate BTF using its API,
      without the need to unnecessarily load it into kernel.
      
      One of the intended use cases is pahole, which will do DWARF to BTF
      conversion and then use libbpf to do type deduplication, while then
      handling ELF sections overwriting and other concerns on its own.
      
      Fixes: 2d3feca8 ("bpf: btf: print map dump and lookup with btf info")
      Signed-off-by: NAndrii Nakryiko <andriin@fb.com>
      Acked-by: NSong Liu <songliubraving@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      d29d87f7
  21. 08 2月, 2019 1 次提交
  22. 05 2月, 2019 5 次提交
    • S
      libbpf: fix libbpf_print · a8a1f7d0
      Stanislav Fomichev 提交于
      With the recent print rework we now have the following problem:
      pr_{warning,info,debug} expand to __pr which calls libbpf_print.
      libbpf_print does va_start and calls __libbpf_pr with va_list argument.
      In __base_pr we again do va_start. Because the next argument is a
      va_list, we don't get correct pointer to the argument (and print noting
      in my case, I don't know why it doesn't crash tbh).
      
      Fix this by changing libbpf_print_fn_t signature to accept va_list and
      remove unneeded calls to va_start in the existing users.
      
      Alternatively, this can we solved by exporting __libbpf_pr and
      changing __pr macro to (and killing libbpf_print):
      {
      	if (__libbpf_pr)
      		__libbpf_pr(level, "libbpf: " fmt, ##__VA_ARGS__)
      }
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Acked-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      a8a1f7d0
    • Y
      tools/bpf: implement libbpf btf__get_map_kv_tids() API function · 96408c43
      Yonghong Song 提交于
      Currently, to get map key/value type id's, the macro
        BPF_ANNOTATE_KV_PAIR(<map_name>, <key_type>, <value_type>)
      needs to be defined in the bpf program for the
      corresponding map.
      
      During program/map loading time,
      the local static function bpf_map_find_btf_info()
      in libbpf.c is implemented to retrieve the key/value
      type ids given the map name.
      
      The patch refactored function bpf_map_find_btf_info()
      to create an API btf__get_map_kv_tids() which includes
      the bulk of implementation for the original function.
      The API btf__get_map_kv_tids() can be used by bcc,
      a JIT based bpf compilation system, which uses the
      same BPF_ANNOTATE_KV_PAIR to record map key/value types.
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      96408c43
    • Y
      tools/bpf: simplify libbpf API function libbpf_set_print() · 6f1ae8b6
      Yonghong Song 提交于
      Currently, the libbpf API function libbpf_set_print()
      takes three function pointer parameters for warning, info
      and debug printout respectively.
      
      This patch changes the API to have just one function pointer
      parameter and the function pointer has one additional
      parameter "debugging level". So if in the future, if
      the debug level is increased, the function signature
      won't change.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      6f1ae8b6
    • Y
      tools/bpf: print out btf log at LIBBPF_WARN level · 9d100a19
      Yonghong Song 提交于
      Currently, the btf log is allocated and printed out in case
      of error at LIBBPF_DEBUG level.
      Such logs from kernel are very important for debugging.
      For example, bpf syscall BPF_PROG_LOAD command can get
      verifier logs back to user space. In function load_program()
      of libbpf.c, the log buffer is allocated unconditionally
      and printed out at pr_warning() level.
      
      Let us do the similar thing here for btf. Allocate buffer
      unconditionally and print out error logs at pr_warning() level.
      This can reduce one global function and
      optimize for common situations where pr_warning()
      is activated either by default or by user supplied
      debug output function.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      9d100a19
    • Y
      tools/bpf: move libbpf pr_* debug print functions to headers · 8461ef8b
      Yonghong Song 提交于
      A global function libbpf_print, which is invisible
      outside the shared library, is defined to print based
      on levels. The pr_warning, pr_info and pr_debug
      macros are moved into the newly created header
      common.h. So any .c file including common.h can
      use these macros directly.
      
      Currently btf__new and btf_ext__new API has an argument getting
      __pr_debug function pointer into btf.c so the debugging information
      can be printed there. This patch removed this parameter
      from btf__new and btf_ext__new and directly using pr_debug in btf.c.
      
      Another global function libbpf_print_level_available, also
      invisible outside the shared library, can test
      whether a particular level debug printing is
      available or not. It is used in btf.c to
      test whether DEBUG level debug printing is availabl or not,
      based on which the log buffer will be allocated when loading
      btf to the kernel.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Signed-off-by: NAlexei Starovoitov <ast@kernel.org>
      8461ef8b