An error occurred fetching the project authors.
  1. 28 May, 2024 1 commit
  2. 30 Apr, 2024 1 commit
  3. 11 Apr, 2024 1 commit
  4. 06 Apr, 2024 1 commit
  5. 20 Mar, 2024 1 commit
  6. 11 Mar, 2024 1 commit
    • Andrii Nakryiko's avatar
      libbpf: Recognize __arena global variables. · 2e7ba4f8
      Andrii Nakryiko authored
      LLVM automatically places __arena variables into ".arena.1" ELF section.
      In order to use such global variables bpf program must include definition
      of arena map in ".maps" section, like:
      struct {
             __uint(type, BPF_MAP_TYPE_ARENA);
             __uint(map_flags, BPF_F_MMAPABLE);
             __uint(max_entries, 1000);         /* number of pages */
             __ulong(map_extra, 2ull << 44);    /* start of mmap() region */
      } arena SEC(".maps");
      
      libbpf recognizes both uses of arena and creates single `struct bpf_map *`
      instance in libbpf APIs.
      ".arena.1" ELF section data is used as initial data image, which is exposed
      through skeleton and bpf_map__initial_value() to the user, if they need to tune
      it before the load phase. During load phase, this initial image is copied over
      into mmap()'ed region corresponding to arena, and discarded.
      
      Few small checks here and there had to be added to make sure this
      approach works with bpf_map__initial_value(), mostly due to hard-coded
      assumption that map->mmaped is set up with mmap() syscall and should be
      munmap()'ed. For arena, .arena.1 can be (much) smaller than maximum
      arena size, so this smaller data size has to be tracked separately.
      Given it is enforced that there is only one arena for entire bpf_object
      instance, we just keep it in a separate field. This can be generalized
      if necessary later.
      
      All global variables from ".arena.1" section are accessible from user space
      via skel->arena->name_of_var.
      
      For bss/data/rodata the skeleton/libbpf perform the following sequence:
      1. addr = mmap(MAP_ANONYMOUS)
      2. user space optionally modifies global vars
      3. map_fd = bpf_create_map()
      4. bpf_update_map_elem(map_fd, addr) // to store values into the kernel
      5. mmap(addr, MAP_FIXED, map_fd)
      after step 5 user spaces see the values it wrote at step 2 at the same addresses
      
      arena doesn't support update_map_elem. Hence skeleton/libbpf do:
      1. addr = malloc(sizeof SEC ".arena.1")
      2. user space optionally modifies global vars
      3. map_fd = bpf_create_map(MAP_TYPE_ARENA)
      4. real_addr = mmap(map->map_extra, MAP_SHARED | MAP_FIXED, map_fd)
      5. memcpy(real_addr, addr) // this will fault-in and allocate pages
      
      At the end look and feel of global data vs __arena global data is the same from
      bpf prog pov.
      
      Another complication is:
      struct {
        __uint(type, BPF_MAP_TYPE_ARENA);
      } arena SEC(".maps");
      
      int __arena foo;
      int bar;
      
        ptr1 = &foo;   // relocation against ".arena.1" section
        ptr2 = &arena; // relocation against ".maps" section
        ptr3 = &bar;   // relocation against ".bss" section
      
      Fo the kernel ptr1 and ptr2 has point to the same arena's map_fd
      while ptr3 points to a different global array's map_fd.
      For the verifier:
      ptr1->type == unknown_scalar
      ptr2->type == const_ptr_to_map
      ptr3->type == ptr_to_map_value
      
      After verification, from JIT pov all 3 ptr-s are normal ld_imm64 insns.
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Acked-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Link: https://lore.kernel.org/bpf/20240308010812.89848-11-alexei.starovoitov@gmail.com
      2e7ba4f8
  7. 25 Jan, 2024 2 commits
    • Andrii Nakryiko's avatar
      libbpf: Support BPF token path setting through LIBBPF_BPF_TOKEN_PATH envvar · cac270ad
      Andrii Nakryiko authored
      To allow external admin authority to override default BPF FS location
      (/sys/fs/bpf) for implicit BPF token creation, teach libbpf to recognize
      LIBBPF_BPF_TOKEN_PATH envvar. If it is specified and user application
      didn't explicitly specify bpf_token_path option, it will be treated
      exactly like bpf_token_path option, overriding default /sys/fs/bpf
      location and making BPF token mandatory.
      Suggested-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20240124022127.2379740-29-andrii@kernel.org
      cac270ad
    • Andrii Nakryiko's avatar
      libbpf: Wire up BPF token support at BPF object level · 6b434b61
      Andrii Nakryiko authored
      Add BPF token support to BPF object-level functionality.
      
      BPF token is supported by BPF object logic either as an explicitly
      provided BPF token from outside (through BPF FS path), or implicitly
      (unless prevented through bpf_object_open_opts).
      
      Implicit mode is assumed to be the most common one for user namespaced
      unprivileged workloads. The assumption is that privileged container
      manager sets up default BPF FS mount point at /sys/fs/bpf with BPF token
      delegation options (delegate_{cmds,maps,progs,attachs} mount options).
      BPF object during loading will attempt to create BPF token from
      /sys/fs/bpf location, and pass it for all relevant operations
      (currently, map creation, BTF load, and program load).
      
      In this implicit mode, if BPF token creation fails due to whatever
      reason (BPF FS is not mounted, or kernel doesn't support BPF token,
      etc), this is not considered an error. BPF object loading sequence will
      proceed with no BPF token.
      
      In explicit BPF token mode, user provides explicitly custom BPF FS mount
      point path. In such case, BPF object will attempt to create BPF token
      from provided BPF FS location. If BPF token creation fails, that is
      considered a critical error and BPF object load fails with an error.
      
      Libbpf provides a way to disable implicit BPF token creation, if it
      causes any troubles (BPF token is designed to be completely optional and
      shouldn't cause any problems even if provided, but in the world of BPF
      LSM, custom security logic can be installed that might change outcome
      depending on the presence of BPF token). To disable libbpf's default BPF
      token creation behavior user should provide either invalid BPF token FD
      (negative), or empty bpf_token_path option.
      
      BPF token presence can influence libbpf's feature probing, so if BPF
      object has associated BPF token, feature probing is instructed to use
      BPF object-specific feature detection cache and token FD.
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20240124022127.2379740-26-andrii@kernel.org
      6b434b61
  8. 19 Dec, 2023 1 commit
  9. 13 Dec, 2023 2 commits
    • Andrii Nakryiko's avatar
      libbpf: support BPF token path setting through LIBBPF_BPF_TOKEN_PATH envvar · ed54124b
      Andrii Nakryiko authored
      To allow external admin authority to override default BPF FS location
      (/sys/fs/bpf) for implicit BPF token creation, teach libbpf to recognize
      LIBBPF_BPF_TOKEN_PATH envvar. If it is specified and user application
      didn't explicitly specify neither bpf_token_path nor bpf_token_fd
      option, it will be treated exactly like bpf_token_path option,
      overriding default /sys/fs/bpf location and making BPF token mandatory.
      Suggested-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20231213190842.3844987-10-andrii@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      ed54124b
    • Andrii Nakryiko's avatar
      libbpf: wire up BPF token support at BPF object level · 1d0dd6ea
      Andrii Nakryiko authored
      Add BPF token support to BPF object-level functionality.
      
      BPF token is supported by BPF object logic either as an explicitly
      provided BPF token from outside (through BPF FS path or explicit BPF
      token FD), or implicitly (unless prevented through
      bpf_object_open_opts).
      
      Implicit mode is assumed to be the most common one for user namespaced
      unprivileged workloads. The assumption is that privileged container
      manager sets up default BPF FS mount point at /sys/fs/bpf with BPF token
      delegation options (delegate_{cmds,maps,progs,attachs} mount options).
      BPF object during loading will attempt to create BPF token from
      /sys/fs/bpf location, and pass it for all relevant operations
      (currently, map creation, BTF load, and program load).
      
      In this implicit mode, if BPF token creation fails due to whatever
      reason (BPF FS is not mounted, or kernel doesn't support BPF token,
      etc), this is not considered an error. BPF object loading sequence will
      proceed with no BPF token.
      
      In explicit BPF token mode, user provides explicitly either custom BPF
      FS mount point path or creates BPF token on their own and just passes
      token FD directly. In such case, BPF object will either dup() token FD
      (to not require caller to hold onto it for entire duration of BPF object
      lifetime) or will attempt to create BPF token from provided BPF FS
      location. If BPF token creation fails, that is considered a critical
      error and BPF object load fails with an error.
      
      Libbpf provides a way to disable implicit BPF token creation, if it
      causes any troubles (BPF token is designed to be completely optional and
      shouldn't cause any problems even if provided, but in the world of BPF
      LSM, custom security logic can be installed that might change outcome
      dependin on the presence of BPF token). To disable libbpf's default BPF
      token creation behavior user should provide either invalid BPF token FD
      (negative), or empty bpf_token_path option.
      
      BPF token presence can influence libbpf's feature probing, so if BPF
      object has associated BPF token, feature probing is instructed to use
      BPF object-specific feature detection cache and token FD.
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20231213190842.3844987-7-andrii@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      1d0dd6ea
  10. 24 Oct, 2023 1 commit
  11. 25 Sep, 2023 6 commits
  12. 24 Aug, 2023 1 commit
  13. 21 Aug, 2023 1 commit
    • Jiri Olsa's avatar
      libbpf: Add bpf_program__attach_uprobe_multi function · 3140cf12
      Jiri Olsa authored
      Adding bpf_program__attach_uprobe_multi function that
      allows to attach multiple uprobes with uprobe_multi link.
      
      The user can specify uprobes with direct arguments:
      
        binary_path/func_pattern/pid
      
      or with struct bpf_uprobe_multi_opts opts argument fields:
      
        const char **syms;
        const unsigned long *offsets;
        const unsigned long *ref_ctr_offsets;
        const __u64 *cookies;
      
      User can specify 2 mutually exclusive set of inputs:
      
       1) use only path/func_pattern/pid arguments
      
       2) use path/pid with allowed combinations of:
          syms/offsets/ref_ctr_offsets/cookies/cnt
      
          - syms and offsets are mutually exclusive
          - ref_ctr_offsets and cookies are optional
      
      Any other usage results in error.
      Signed-off-by: default avatarJiri Olsa <jolsa@kernel.org>
      Link: https://lore.kernel.org/r/20230809083440.3209381-15-jolsa@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      3140cf12
  14. 19 Jul, 2023 2 commits
  15. 30 Jun, 2023 1 commit
  16. 24 May, 2023 1 commit
  17. 27 Mar, 2023 1 commit
  18. 23 Mar, 2023 1 commit
  19. 06 Mar, 2023 1 commit
  20. 08 Feb, 2023 1 commit
  21. 03 Feb, 2023 1 commit
  22. 27 Jan, 2023 2 commits
  23. 29 Dec, 2022 1 commit
  24. 23 Sep, 2022 1 commit
  25. 21 Sep, 2022 1 commit
    • David Vernet's avatar
      bpf: Add libbpf logic for user-space ring buffer · b66ccae0
      David Vernet authored
      Now that all of the logic is in place in the kernel to support user-space
      produced ring buffers, we can add the user-space logic to libbpf. This
      patch therefore adds the following public symbols to libbpf:
      
      struct user_ring_buffer *
      user_ring_buffer__new(int map_fd,
      		      const struct user_ring_buffer_opts *opts);
      void *user_ring_buffer__reserve(struct user_ring_buffer *rb, __u32 size);
      void *user_ring_buffer__reserve_blocking(struct user_ring_buffer *rb,
                                               __u32 size, int timeout_ms);
      void user_ring_buffer__submit(struct user_ring_buffer *rb, void *sample);
      void user_ring_buffer__discard(struct user_ring_buffer *rb,
      void user_ring_buffer__free(struct user_ring_buffer *rb);
      
      A user-space producer must first create a struct user_ring_buffer * object
      with user_ring_buffer__new(), and can then reserve samples in the
      ring buffer using one of the following two symbols:
      
      void *user_ring_buffer__reserve(struct user_ring_buffer *rb, __u32 size);
      void *user_ring_buffer__reserve_blocking(struct user_ring_buffer *rb,
                                               __u32 size, int timeout_ms);
      
      With user_ring_buffer__reserve(), a pointer to a 'size' region of the ring
      buffer will be returned if sufficient space is available in the buffer.
      user_ring_buffer__reserve_blocking() provides similar semantics, but will
      block for up to 'timeout_ms' in epoll_wait if there is insufficient space
      in the buffer. This function has the guarantee from the kernel that it will
      receive at least one event-notification per invocation to
      bpf_ringbuf_drain(), provided that at least one sample is drained, and the
      BPF program did not pass the BPF_RB_NO_WAKEUP flag to bpf_ringbuf_drain().
      
      Once a sample is reserved, it must either be committed to the ring buffer
      with user_ring_buffer__submit(), or discarded with
      user_ring_buffer__discard().
      Signed-off-by: default avatarDavid Vernet <void@manifault.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220920000100.477320-4-void@manifault.com
      b66ccae0
  26. 17 Aug, 2022 1 commit
  27. 19 Jul, 2022 1 commit
    • Andrii Nakryiko's avatar
      libbpf: add ksyscall/kretsyscall sections support for syscall kprobes · 708ac5be
      Andrii Nakryiko authored
      Add SEC("ksyscall")/SEC("ksyscall/<syscall_name>") and corresponding
      kretsyscall variants (for return kprobes) to allow users to kprobe
      syscall functions in kernel. These special sections allow to ignore
      complexities and differences between kernel versions and host
      architectures when it comes to syscall wrapper and corresponding
      __<arch>_sys_<syscall> vs __se_sys_<syscall> differences, depending on
      whether host kernel has CONFIG_ARCH_HAS_SYSCALL_WRAPPER (though libbpf
      itself doesn't rely on /proc/config.gz for detecting this, see
      BPF_KSYSCALL patch for how it's done internally).
      
      Combined with the use of BPF_KSYSCALL() macro, this allows to just
      specify intended syscall name and expected input arguments and leave
      dealing with all the variations to libbpf.
      
      In addition to SEC("ksyscall+") and SEC("kretsyscall+") add
      bpf_program__attach_ksyscall() API which allows to specify syscall name
      at runtime and provide associated BPF cookie value.
      
      At the moment SEC("ksyscall") and bpf_program__attach_ksyscall() do not
      handle all the calling convention quirks for mmap(), clone() and compat
      syscalls. It also only attaches to "native" syscall interfaces. If host
      system supports compat syscalls or defines 32-bit syscalls in 64-bit
      kernel, such syscall interfaces won't be attached to by libbpf.
      
      These limitations may or may not change in the future. Therefore it is
      recommended to use SEC("kprobe") for these syscalls or if working with
      compat and 32-bit interfaces is required.
      Tested-by: default avatarAlan Maguire <alan.maguire@oracle.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/r/20220714070755.3235561-5-andrii@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      708ac5be
  28. 15 Jul, 2022 1 commit
    • Jon Doron's avatar
      libbpf: perfbuf: Add API to get the ring buffer · 9ff5efde
      Jon Doron authored
      Add support for writing a custom event reader, by exposing the ring
      buffer.
      
      With the new API perf_buffer__buffer() you will get access to the
      raw mmaped()'ed per-cpu underlying memory of the ring buffer.
      
      This region contains both the perf buffer data and header
      (struct perf_event_mmap_page), which manages the ring buffer
      state (head/tail positions, when accessing the head/tail position
      it's important to take into consideration SMP).
      With this type of low level access one can implement different types of
      consumers here are few simple examples where this API helps with:
      
      1. perf_event_read_simple is allocating using malloc, perhaps you want
         to handle the wrap-around in some other way.
      2. Since perf buf is per-cpu then the order of the events is not
         guarnteed, for example:
         Given 3 events where each event has a timestamp t0 < t1 < t2,
         and the events are spread on more than 1 CPU, then we can end
         up with the following state in the ring buf:
         CPU[0] => [t0, t2]
         CPU[1] => [t1]
         When you consume the events from CPU[0], you could know there is
         a t1 missing, (assuming there are no drops, and your event data
         contains a sequential index).
         So now one can simply do the following, for CPU[0], you can store
         the address of t0 and t2 in an array (without moving the tail, so
         there data is not perished) then move on the CPU[1] and set the
         address of t1 in the same array.
         So you end up with something like:
         void **arr[] = [&t0, &t1, &t2], now you can consume it orderely
         and move the tails as you process in order.
      3. Assuming there are multiple CPUs and we want to start draining the
         messages from them, then we can "pick" with which one to start with
         according to the remaining free space in the ring buffer.
      Signed-off-by: default avatarJon Doron <jond@wiz.io>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220715181122.149224-1-arilou@gmail.com
      9ff5efde
  29. 28 Jun, 2022 3 commits