1. 21 Aug, 2020 14 commits
  2. 20 Aug, 2020 10 commits
    • Andrii Nakryiko's avatar
      selftests/bpf: List newest Clang built-ins needed for some CO-RE selftests · 149cb339
      Andrii Nakryiko authored
      Record which built-ins are optional and needed for some of recent BPF CO-RE
      subtests. Document Clang diff that fixed corner-case issue with
      __builtin_btf_type_id().
      Suggested-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-4-andriin@fb.com
      149cb339
    • Andrii Nakryiko's avatar
      selftests/bpf: Fix two minor compilation warnings reported by GCC 4.9 · 37a6a9e7
      Andrii Nakryiko authored
      GCC 4.9 seems to be more strict in some regards. Fix two minor issue it
      reported.
      
      Fixes: 1c1052e0 ("tools/testing/selftests/bpf: Add self-tests for new helper bpf_get_ns_current_pid_tgid.")
      Fixes: 2d7824ff ("selftests: bpf: Add test for sk_assign")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-3-andriin@fb.com
      37a6a9e7
    • Andrii Nakryiko's avatar
      libbpf: Fix libbpf build on compilers missing __builtin_mul_overflow · dda1ec9f
      Andrii Nakryiko authored
      GCC compilers older than version 5 don't support __builtin_mul_overflow yet.
      Given GCC 4.9 is the minimal supported compiler for building kernel and the
      fact that libbpf is a dependency of resolve_btfids, which is dependency of
      CONFIG_DEBUG_INFO_BTF=y, this needs to be handled. This patch fixes the issue
      by falling back to slower detection of integer overflow in such cases.
      
      Fixes: 029258d7 ("libbpf: Remove any use of reallocarray() in libbpf")
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-2-andriin@fb.com
      dda1ec9f
    • Andrii Nakryiko's avatar
      libbpf: Fix detection of BPF helper call instruction · 9b2f6fec
      Andrii Nakryiko authored
      BPF_CALL | BPF_JMP32 is explicitly not allowed by verifier for BPF helper
      calls, so don't detect it as a valid call. Also drop the check on func_id
      pointer, as it's currently always non-null.
      
      Fixes: 109cea5a ("libbpf: Sanitize BPF program code for bpf_probe_read_{kernel, user}[_str]")
      Reported-by: default avatarYonghong Song <yhs@fb.com>
      Signed-off-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20200820061411.1755905-1-andriin@fb.com
      9b2f6fec
    • Daniel Borkmann's avatar
      Merge branch 'bpf-umd-debug' · 0bc23a1d
      Daniel Borkmann authored
      Alexei Starovoitov says:
      
      ====================
      This patch set is the first real user of user mode driver facility. The
      general use case for user mode driver is to ship vmlinux with preloaded BPF
      programs. In this particular case the user mode driver populates bpffs instance
      with two BPF iterators. In several months BPF_LSM project would need to preload
      the kernel with its own set of BPF programs and attach to LSM hooks instead of
      bpffs. BPF iterators and BPF_LSM are unstable from uapi perspective. They are
      tracing based and peek into arbitrary kernel data structures. One can question
      why a kernel module cannot embed BPF programs inside. The reason is that libbpf
      is necessary to load them. First libbpf loads BPF Type Format, then creates BPF
      maps, populates them. Then it relocates code sections inside BPF programs,
      loads BPF programs, and finally attaches them to events. Theoretically libbpf
      can be rewritten to work in the kernel, but that is massive undertaking. The
      maintenance of in-kernel libbpf and user space libbpf would be another
      challenge. Another obstacle to embedding BPF programs into kernel module is
      sys_bpf api. Loading of programs, BTF, maps goes through the verifier. It
      validates and optimizes the code. It's possible to provide in-kernel api to all
      of sys_bpf commands (load progs, create maps, update maps, load BTF, etc), but
      that is huge amount of work and forever maintenance headache.
      Hence the decision is to ship vmlinux with user mode drivers that load
      BPF programs. Just like kernel modules extend vmlinux BPF programs
      are safe extensions of the kernel and some of them need to ship with vmlinux.
      
      This patch set adds a kernel module with user mode driver that populates bpffs
      with two BPF iterators.
      
      $ mount bpffs /my/bpffs/ -t bpf
      $ ls -la /my/bpffs/
      total 4
      drwxrwxrwt  2 root root    0 Jul  2 00:27 .
      drwxr-xr-x 19 root root 4096 Jul  2 00:09 ..
      -rw-------  1 root root    0 Jul  2 00:27 maps.debug
      -rw-------  1 root root    0 Jul  2 00:27 progs.debug
      
      The user mode driver will load BPF Type Formats, create BPF maps, populate BPF
      maps, load two BPF programs, attach them to BPF iterators, and finally send two
      bpf_link IDs back to the kernel.
      The kernel will pin two bpf_links into newly mounted bpffs instance under
      names "progs.debug" and "maps.debug". These two files become human readable.
      
      $ cat /my/bpffs/progs.debug
        id name            attached
        11 dump_bpf_map    bpf_iter_bpf_map
        12 dump_bpf_prog   bpf_iter_bpf_prog
        27 test_pkt_access
        32 test_main       test_pkt_access test_pkt_access
        33 test_subprog1   test_pkt_access_subprog1 test_pkt_access
        34 test_subprog2   test_pkt_access_subprog2 test_pkt_access
        35 test_subprog3   test_pkt_access_subprog3 test_pkt_access
        36 new_get_skb_len get_skb_len test_pkt_access
        37 new_get_skb_ifindex get_skb_ifindex test_pkt_access
        38 new_get_constant get_constant test_pkt_access
      
      The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
      all BPF programs currently loaded in the system. This information is unstable
      and will change from kernel to kernel.
      
      In some sence this output is similar to 'bpftool prog show' that is using
      stable api to retreive information about BPF programs. The BPF subsytems grows
      quickly and there is always demand to show as much info about BPF things as
      possible. But we cannot expose all that info via stable uapi of bpf syscall,
      since the details change so much. Right now a BPF program can be attached to
      only one other BPF program. Folks are working on patches to enable
      multi-attach, but for debugging it's necessary to see the current state. There
      is no uapi for that, but above output shows it:
        37 new_get_skb_ifindex  get_skb_ifindex test_pkt_access
        38 new_get_constant     get_constant    test_pkt_access
           [1]                  [2]             [3]
      [1] is the full name of BPF prog from BTF.
      [2] is the name of function inside target BPF prog.
      [3] is the name of target BPF prog.
      
      [2] and [3] are not exposed via uapi, since they will change from single to
      multi soon. There are many other cases where bpf internals are useful for
      debugging, but shouldn't be exposed via uapi due to high rate of changes.
      
      systemd mounts /sys/fs/bpf at the start, so this kernel module with user mode
      driver needs to be available early. BPF_LSM most likely would need to preload
      BPF programs even earlier.
      
      Few interesting observations:
      - though bpffs comes with two human readble files "progs.debug" and
        "maps.debug" they can be removed. 'rm -f /sys/fs/bpf/progs.debug' will remove
        bpf_link and kernel will automatically unload corresponding BPF progs, maps,
        BTFs. In the future '-o remount' will be able to restore them. This is not
        implemented yet.
      
      - 'ps aux|grep bpf_preload' shows nothing. User mode driver loaded BPF
        iterators and exited. Nothing is lingering in user space at this point.
      
      - We can consider giving 0644 permissions to "progs.debug" and "maps.debug"
        to allow unprivileged users see BPF things loaded in the system.
        We cannot do so with "bpftool prog show", since it's using cap_sys_admin
        parts of bpf syscall.
      
      - The functionality split between core kernel, bpf_preload kernel module and
        user mode driver is very similar to bpfilter style of interaction.
      
      - Similar BPF iterators can be used as unstable extensions to /proc.
        Like mounting /proc can prepopolate some subdirectory in there with
        a BPF iterator that will print QUIC sockets instead of tcp and udp.
      
      Changelog:
      
      v5->v6:
      - refactored Makefiles with Andrii's help
        - switched to explicit $(MAKE) style
        - switched to userldlibs instead of userldflags
        - fixed build issue with libbpf Makefile due to invocation from kbuild
      - fixed menuconfig order as spotted by Daniel
      - introduced CONFIG_USERMODE_DRIVER bool that is selected by bpfilter and bpf_preload
      
      v4->v5:
      - addressed Song and Andrii feedback. s/pages/max_entries/
      
      v3->v4:
      - took THIS_MODULE in patch 3 as suggested by Daniel to simplify the code.
      - converted BPF iterator to use BTF (when available) to print full BPF program name
      instead of 16-byte truncated version.
      This is something I've been using drgn scripts for.
      Take a look at get_name() in iterators.bpf.c to see how short it is comparing
      to what user space bpftool would have to do to print the same full name:
      . get prog info via obj_info_by_fd
      . do get_fd_by_id from info->btf_id
      . fetch potentially large BTF of the program from the kernel
      . parse that BTF in user space to figure out all type boundaries and string section
      . read info->func_info to get btf_id of func_proto from there
      . find that btf_id in the parsed BTF
      That's quite a bit work for bpftool comparing to few lines in get_name().
      I guess would be good to make bpftool do this info extraction anyway.
      While doing this BTF reading in the kernel realized that the verifier is not smart
      enough to follow double pointers (added to my todo list), otherwise get_name()
      would have been even shorter.
      
      v2->v3:
      - fixed module unload race (Daniel)
      - added selftest (Daniel)
      - fixed build bot warning
      
      v1->v2:
      - changed names to 'progs.debug' and 'maps.debug' to hopefully better indicate
        instability of the text output. Having dot in the name also guarantees
        that these special files will not conflict with normal bpf objects pinned
        in bpffs, since dot is disallowed for normal pins.
      - instead of hard coding link_name in the core bpf moved into UMD.
      - cleanedup error handling.
      - addressed review comments from Yonghong and Andrii.
      ====================
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      0bc23a1d
    • Alexei Starovoitov's avatar
      selftests/bpf: Add bpffs preload test. · edb65ee5
      Alexei Starovoitov authored
      Add a test that mounts two bpffs instances and checks progs.debug
      and maps.debug for sanity data.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-5-alexei.starovoitov@gmail.com
      edb65ee5
    • Alexei Starovoitov's avatar
      bpf: Add kernel module with user mode driver that populates bpffs. · d71fa5c9
      Alexei Starovoitov authored
      Add kernel module with user mode driver that populates bpffs with
      BPF iterators.
      
      $ mount bpffs /my/bpffs/ -t bpf
      $ ls -la /my/bpffs/
      total 4
      drwxrwxrwt  2 root root    0 Jul  2 00:27 .
      drwxr-xr-x 19 root root 4096 Jul  2 00:09 ..
      -rw-------  1 root root    0 Jul  2 00:27 maps.debug
      -rw-------  1 root root    0 Jul  2 00:27 progs.debug
      
      The user mode driver will load BPF Type Formats, create BPF maps, populate BPF
      maps, load two BPF programs, attach them to BPF iterators, and finally send two
      bpf_link IDs back to the kernel.
      The kernel will pin two bpf_links into newly mounted bpffs instance under
      names "progs.debug" and "maps.debug". These two files become human readable.
      
      $ cat /my/bpffs/progs.debug
        id name            attached
        11 dump_bpf_map    bpf_iter_bpf_map
        12 dump_bpf_prog   bpf_iter_bpf_prog
        27 test_pkt_access
        32 test_main       test_pkt_access test_pkt_access
        33 test_subprog1   test_pkt_access_subprog1 test_pkt_access
        34 test_subprog2   test_pkt_access_subprog2 test_pkt_access
        35 test_subprog3   test_pkt_access_subprog3 test_pkt_access
        36 new_get_skb_len get_skb_len test_pkt_access
        37 new_get_skb_ifindex get_skb_ifindex test_pkt_access
        38 new_get_constant get_constant test_pkt_access
      
      The BPF program dump_bpf_prog() in iterators.bpf.c is printing this data about
      all BPF programs currently loaded in the system. This information is unstable
      and will change from kernel to kernel as ".debug" suffix conveys.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-4-alexei.starovoitov@gmail.com
      d71fa5c9
    • Alexei Starovoitov's avatar
      bpf: Add BPF program and map iterators as built-in BPF programs. · f0fdfefb
      Alexei Starovoitov authored
      The program and map iterators work similar to seq_file-s.
      Once the program is pinned in bpffs it can be read with "cat" tool
      to print human readable output. In this case about BPF programs and maps.
      For example:
      $ cat /sys/fs/bpf/progs.debug
        id name            attached
         5 dump_bpf_map    bpf_iter_bpf_map
         6 dump_bpf_prog   bpf_iter_bpf_prog
      $ cat /sys/fs/bpf/maps.debug
        id name            max_entries
         3 iterator.rodata     1
      
      To avoid kernel build dependency on clang 10 separate bpf skeleton generation
      into manual "make" step and instead check-in generated .skel.h into git.
      
      Unlike 'bpftool prog show' in-kernel BTF name is used (when available)
      to print full name of BPF program instead of 16-byte truncated name.
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-3-alexei.starovoitov@gmail.com
      f0fdfefb
    • Alexei Starovoitov's avatar
      bpf: Factor out bpf_link_by_id() helper. · 005142b8
      Alexei Starovoitov authored
      Refactor the code a bit to extract bpf_link_by_id() helper.
      It's similar to existing bpf_prog_by_id().
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarAndrii Nakryiko <andriin@fb.com>
      Acked-by: default avatarSong Liu <songliubraving@fb.com>
      Link: https://lore.kernel.org/bpf/20200819042759.51280-2-alexei.starovoitov@gmail.com
      005142b8
    • Xu Wang's avatar
  3. 19 Aug, 2020 16 commits