Skip to content
Snippets Groups Projects
  1. Jan 10, 2020
  2. Dec 19, 2019
  3. Dec 16, 2019
    • Andrii Nakryiko's avatar
      libbpf: Support libbpf-provided extern variables · 166750bc
      Andrii Nakryiko authored
      
      Add support for extern variables, provided to BPF program by libbpf. Currently
      the following extern variables are supported:
        - LINUX_KERNEL_VERSION; version of a kernel in which BPF program is
          executing, follows KERNEL_VERSION() macro convention, can be 4- and 8-byte
          long;
        - CONFIG_xxx values; a set of values of actual kernel config. Tristate,
          boolean, strings, and integer values are supported.
      
      Set of possible values is determined by declared type of extern variable.
      Supported types of variables are:
      - Tristate values. Are represented as `enum libbpf_tristate`. Accepted values
        are **strictly** 'y', 'n', or 'm', which are represented as TRI_YES, TRI_NO,
        or TRI_MODULE, respectively.
      - Boolean values. Are represented as bool (_Bool) types. Accepted values are
        'y' and 'n' only, turning into true/false values, respectively.
      - Single-character values. Can be used both as a substritute for
        bool/tristate, or as a small-range integer:
        - 'y'/'n'/'m' are represented as is, as characters 'y', 'n', or 'm';
        - integers in a range [-128, 127] or [0, 255] (depending on signedness of
          char in target architecture) are recognized and represented with
          respective values of char type.
      - Strings. String values are declared as fixed-length char arrays. String of
        up to that length will be accepted and put in first N bytes of char array,
        with the rest of bytes zeroed out. If config string value is longer than
        space alloted, it will be truncated and warning message emitted. Char array
        is always zero terminated. String literals in config have to be enclosed in
        double quotes, just like C-style string literals.
      - Integers. 8-, 16-, 32-, and 64-bit integers are supported, both signed and
        unsigned variants. Libbpf enforces parsed config value to be in the
        supported range of corresponding integer type. Integers values in config can
        be:
        - decimal integers, with optional + and - signs;
        - hexadecimal integers, prefixed with 0x or 0X;
        - octal integers, starting with 0.
      
      Config file itself is searched in /boot/config-$(uname -r) location with
      fallback to /proc/config.gz, unless config path is specified explicitly
      through bpf_object_open_opts' kernel_config_path option. Both gzipped and
      plain text formats are supported. Libbpf adds explicit dependency on zlib
      because of this, but this shouldn't be a problem, given libelf already depends
      on zlib.
      
      All detected extern variables, are put into a separate .extern internal map.
      It, similarly to .rodata map, is marked as read-only from BPF program side, as
      well as is frozen on load. This allows BPF verifier to track extern values as
      constants and perform enhanced branch prediction and dead code elimination.
      This can be relied upon for doing kernel version/feature detection and using
      potentially unsupported field relocations or BPF helpers in a CO-RE-based BPF
      program, while still having a single version of BPF program running on old and
      new kernels. Selftests are validating this explicitly for unexisting BPF
      helper.
      
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20191214014710.3449601-3-andriin@fb.com
      166750bc
  4. Nov 25, 2019
  5. Nov 15, 2019
  6. Nov 02, 2019
    • Toke Høiland-Jørgensen's avatar
      libbpf: Add auto-pinning of maps when loading BPF objects · 57a00f41
      Toke Høiland-Jørgensen authored
      
      This adds support to libbpf for setting map pinning information as part of
      the BTF map declaration, to get automatic map pinning (and reuse) on load.
      The pinning type currently only supports a single PIN_BY_NAME mode, where
      each map will be pinned by its name in a path that can be overridden, but
      defaults to /sys/fs/bpf.
      
      Since auto-pinning only does something if any maps actually have a
      'pinning' BTF attribute set, we default the new option to enabled, on the
      assumption that seamless pinning is what most callers want.
      
      When a map has a pin_path set at load time, libbpf will compare the map
      pinned at that location (if any), and if the attributes match, will re-use
      that map instead of creating a new one. If no existing map is found, the
      newly created map will instead be pinned at the location.
      
      Programs wanting to customise the pinning can override the pinning paths
      using bpf_map__set_pin_path() before calling bpf_object__load() (including
      setting it to NULL to disable pinning of a particular map).
      
      Signed-off-by: default avatarToke Høiland-Jørgensen <toke@redhat.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/157269298092.394725.3966306029218559681.stgit@toke.dk
      57a00f41
  7. Oct 08, 2019
  8. Oct 07, 2019
  9. Oct 06, 2019
  10. Sep 16, 2019
    • Ilya Leoshkevich's avatar
      selftests/bpf: add bpf-gcc support · 4ce150b6
      Ilya Leoshkevich authored
      
      Now that binutils and gcc support for BPF is upstream, make use of it in
      BPF selftests using alu32-like approach. Share as much as possible of
      CFLAGS calculation with clang.
      
      Fixes only obvious issues, leaving more complex ones for later:
      - Use gcc-provided bpf-helpers.h instead of manually defining the
        helpers, change bpf_helpers.h include guard to avoid conflict.
      - Include <linux/stddef.h> for __always_inline.
      - Add $(OUTPUT)/../usr/include to include path in order to use local
        kernel headers instead of system kernel headers when building with O=.
      
      In order to activate the bpf-gcc support, one needs to configure
      binutils and gcc with --target=bpf and make them available in $PATH. In
      particular, gcc must be installed as `bpf-gcc`, which is the default.
      
      Right now with binutils 25a2915e8dba and gcc r275589 only a handful of
      tests work:
      
      	# ./test_progs_bpf_gcc
      	# Summary: 7/39 PASSED, 1 SKIPPED, 98 FAILED
      
      The reason for those failures are as follows:
      
      - Build errors:
        - `error: too many function arguments for eBPF` for __always_inline
          functions read_str_var and read_map_var - must be inlining issue,
          and for process_l3_headers_v6, which relies on optimizing away
          function arguments.
        - `error: indirect call in function, which are not supported by eBPF`
          where there are no obvious indirect calls in the source calls, e.g.
          in __encap_ipip_none.
        - `error: field 'lock' has incomplete type` for fields of `struct
          bpf_spin_lock` type - bpf_spin_lock is re#defined by bpf-helpers.h,
          so its usage is sensitive to order of #includes.
        - `error: eBPF stack limit exceeded` in sysctl_tcp_mem.
      - Load errors:
        - Missing object files due to above build errors.
        - `libbpf: failed to create map (name: 'test_ver.bss')`.
        - `libbpf: object file doesn't contain bpf program`.
        - `libbpf: Program '.text' contains unrecognized relo data pointing to
          section 0`.
        - `libbpf: BTF is required, but is missing or corrupted` - no BTF
          support in gcc yet.
      
      Signed-off-by: default avatarIlya Leoshkevich <iii@linux.ibm.com>
      Cc: Jose E. Marchesi <jose.marchesi@oracle.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      4ce150b6
  11. Aug 17, 2019
  12. Aug 07, 2019
  13. Jul 31, 2019
  14. Jul 12, 2019
  15. Jul 05, 2019
  16. Jun 11, 2019
  17. May 24, 2019
  18. May 17, 2019
  19. Apr 27, 2019
  20. Apr 12, 2019
  21. Apr 10, 2019
    • Joe Stringer's avatar
      bpf, selftest: test global data/bss/rodata sections · b915ebe6
      Joe Stringer authored
      
      Add tests for libbpf relocation of static variable references
      into the .data, .rodata and .bss sections of the ELF, also add
      read-only test for .rodata. All passing:
      
        # ./test_progs
        [...]
        test_global_data:PASS:load program 0 nsec
        test_global_data:PASS:pass global data run 925 nsec
        test_global_data_number:PASS:relocate .bss reference 925 nsec
        test_global_data_number:PASS:relocate .data reference 925 nsec
        test_global_data_number:PASS:relocate .rodata reference 925 nsec
        test_global_data_number:PASS:relocate .bss reference 925 nsec
        test_global_data_number:PASS:relocate .data reference 925 nsec
        test_global_data_number:PASS:relocate .rodata reference 925 nsec
        test_global_data_number:PASS:relocate .bss reference 925 nsec
        test_global_data_number:PASS:relocate .bss reference 925 nsec
        test_global_data_number:PASS:relocate .rodata reference 925 nsec
        test_global_data_number:PASS:relocate .rodata reference 925 nsec
        test_global_data_number:PASS:relocate .rodata reference 925 nsec
        test_global_data_string:PASS:relocate .rodata reference 925 nsec
        test_global_data_string:PASS:relocate .data reference 925 nsec
        test_global_data_string:PASS:relocate .bss reference 925 nsec
        test_global_data_string:PASS:relocate .data reference 925 nsec
        test_global_data_string:PASS:relocate .bss reference 925 nsec
        test_global_data_struct:PASS:relocate .rodata reference 925 nsec
        test_global_data_struct:PASS:relocate .bss reference 925 nsec
        test_global_data_struct:PASS:relocate .rodata reference 925 nsec
        test_global_data_struct:PASS:relocate .data reference 925 nsec
        test_global_data_rdonly:PASS:test .rodata read-only map 925 nsec
        [...]
        Summary: 229 PASSED, 0 FAILED
      
      Note map helper signatures have been changed to avoid warnings
      when passing in const data.
      
      Joint work with Daniel Borkmann.
      
      Signed-off-by: default avatarJoe Stringer <joe@wand.net.nz>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Acked-by: default avatarMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      b915ebe6
  22. Mar 22, 2019
  23. Mar 21, 2019
  24. Mar 13, 2019
  25. Mar 02, 2019
  26. Feb 28, 2019
  27. Feb 11, 2019
  28. Feb 01, 2019
  29. Dec 09, 2018
  30. Dec 01, 2018
    • Joe Stringer's avatar
      bpf: Support sk lookup in netns with id 0 · f71c6143
      Joe Stringer authored
      
      David Ahern and Nicolas Dichtel report that the handling of the netns id
      0 is incorrect for the BPF socket lookup helpers: rather than finding
      the netns with id 0, it is resolving to the current netns. This renders
      the netns_id 0 inaccessible.
      
      To fix this, adjust the API for the netns to treat all negative s32
      values as a lookup in the current netns (including u64 values which when
      truncated to s32 become negative), while any values with a positive
      value in the signed 32-bit integer space would result in a lookup for a
      socket in the netns corresponding to that id. As before, if the netns
      with that ID does not exist, no socket will be found. Any netns outside
      of these ranges will fail to find a corresponding socket, as those
      values are reserved for future usage.
      
      Signed-off-by: default avatarJoe Stringer <joe@wand.net.nz>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: default avatarJoey Pabalinas <joeypabalinas@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      f71c6143
  31. Nov 28, 2018
  32. Oct 20, 2018
Loading