1. 16 Feb, 2022 3 commits
  2. 15 Feb, 2022 6 commits
    • Hou Tao's avatar
      bpf: Reject kfunc calls that overflow insn->imm · 8cbf062a
      Hou Tao authored
      Now kfunc call uses s32 to represent the offset between the address of
      kfunc and __bpf_call_base, but it doesn't check whether or not s32 will
      be overflowed. The overflow is possible when kfunc is in module and the
      offset between module and kernel is greater than 2GB. Take arm64 as an
      example, before commit b2eed9b5 ("arm64/kernel: kaslr: reduce module
      randomization range to 2 GB"), the offset between module symbol and
      __bpf_call_base will in 4GB range due to KASLR and may overflow s32.
      
      So add an extra checking to reject these invalid kfunc calls.
      Signed-off-by: default avatarHou Tao <houtao1@huawei.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/20220215065732.3179408-1-houtao1@huawei.com
      8cbf062a
    • Alexei Starovoitov's avatar
      Merge branch 'Make BPF skeleton easier to use from C++ code' · d2b94f33
      Alexei Starovoitov authored
      Andrii Nakryiko says:
      
      ====================
      
      Add minimal C++-specific additions to BPF skeleton codegen to facilitate
      easier use of C skeletons in C++ applications. These additions don't add any
      extra ongoing maintenance and allows C++ users to fit pure C skeleton better
      into their C++ code base. All that without the need to design, implement and
      support a separate C++ BPF skeleton implementation.
      
      v1->v2:
        - use default argument values in T::open() (Alexei).
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      d2b94f33
    • Andrii Nakryiko's avatar
      selftests/bpf: Add Skeleton templated wrapper as an example · 189e0eca
      Andrii Nakryiko authored
      Add an example of how to build C++ template-based BPF skeleton wrapper.
      It's an actually runnable valid use of skeleton through more C++-like
      interface. Note that skeleton destuction happens implicitly through
      Skeleton<T>'s destructor.
      
      Also make test_cpp runnable as it would have crashed on invalid btf
      passed into btf_dump__new().
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220212055733.539056-3-andrii@kernel.org
      189e0eca
    • Andrii Nakryiko's avatar
      bpftool: Add C++-specific open/load/etc skeleton wrappers · bb8ffe61
      Andrii Nakryiko authored
      Add C++-specific static methods for code-generated BPF skeleton for each
      skeleton operation: open, open_opts, open_and_load, load, attach,
      detach, destroy, and elf_bytes. This is to facilitate easier C++
      templating on top of pure C BPF skeleton.
      
      In C, open/load/destroy/etc "methods" are of the form
      <skeleton_name>__<method>() to avoid name collision with similar
      "methods" of other skeletons withint the same application. This works
      well, but is very inconvenient for C++ applications that would like to
      write generic (templated) wrappers around BPF skeleton to fit in with
      C++ code base and take advantage of destructors and other convenient C++
      constructs.
      
      This patch makes it easier to build such generic templated wrappers by
      additionally defining C++ static methods for skeleton's struct with
      fixed names. This allows to refer to, say, open method as `T::open()`
      instead of having to somehow generate `T__open()` function call.
      
      Next patch adds an example template to test_cpp selftest to demonstrate
      how it's possible to have all the operations wrapped in a generic
      Skeleton<my_skeleton> type without explicitly passing function references.
      
      An example of generated declaration section without %1$s placeholders:
      
        #ifdef __cplusplus
            static struct test_attach_probe *open(const struct bpf_object_open_opts *opts = nullptr);
            static struct test_attach_probe *open_and_load();
            static int load(struct test_attach_probe *skel);
            static int attach(struct test_attach_probe *skel);
            static void detach(struct test_attach_probe *skel);
            static void destroy(struct test_attach_probe *skel);
            static const void *elf_bytes(size_t *sz);
        #endif /* __cplusplus */
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220212055733.539056-2-andrii@kernel.org
      bb8ffe61
    • Andrii Nakryiko's avatar
      selftests/bpf: Fix GCC11 compiler warnings in -O2 mode · d3b0b800
      Andrii Nakryiko authored
      When compiling selftests in -O2 mode with GCC1, we get three new
      compilations warnings about potentially uninitialized variables.
      
      Compiler is wrong 2 out of 3 times, but this patch makes GCC11 happy
      anyways, as it doesn't cost us anything and makes optimized selftests
      build less annoying.
      
      The amazing one is tc_redirect case of token that is malloc()'ed before
      ASSERT_OK_PTR() check is done on it. Seems like GCC pessimistically
      assumes that libbpf_get_error() will dereference the contents of the
      pointer (no it won't), so the only way I found to shut GCC up was to do
      zero-initializaing calloc(). This one was new to me.
      
      For linfo case, GCC didn't realize that linfo_size will be initialized
      by the function that is returning linfo_size as out parameter.
      
      core_reloc.c case was a real bug, we can goto cleanup before initializing
      obj. But we don't need to do any clean up, so just continue iteration
      intstead.
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220211190927.1434329-1-andrii@kernel.org
      d3b0b800
    • Yinjun Zhang's avatar
      bpftool: Fix the error when lookup in no-btf maps · edc21dc9
      Yinjun Zhang authored
      When reworking btf__get_from_id() in commit a19f93cf the error
      handling when calling bpf_btf_get_fd_by_id() changed. Before the rework
      if bpf_btf_get_fd_by_id() failed the error would not be propagated to
      callers of btf__get_from_id(), after the rework it is. This lead to a
      change in behavior in print_key_value() that now prints an error when
      trying to lookup keys in maps with no btf available.
      
      Fix this by following the way used in dumping maps to allow to look up
      keys in no-btf maps, by which it decides whether and where to get the
      btf info according to the btf value type.
      
      Fixes: a19f93cf ("libbpf: Add internal helper to load BTF data by FD")
      Signed-off-by: default avatarYinjun Zhang <yinjun.zhang@corigine.com>
      Signed-off-by: default avatarSimon Horman <simon.horman@corigine.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Reviewed-by: default avatarNiklas Söderlund <niklas.soderlund@corigine.com>
      Acked-by: default avatarJiri Olsa <jolsa@kernel.org>
      Link: https://lore.kernel.org/bpf/1644249625-22479-1-git-send-email-yinjun.zhang@corigine.com
      edc21dc9
  3. 12 Feb, 2022 1 commit
  4. 11 Feb, 2022 6 commits
    • Andrii Nakryiko's avatar
      libbpf: Fix libbpf.map inheritance chain for LIBBPF_0.7.0 · d130e954
      Andrii Nakryiko authored
      Ensure that LIBBPF_0.7.0 inherits everything from LIBBPF_0.6.0.
      
      Fixes: dbdd2c7f ("libbpf: Add API to get/set log_level at per-program level")
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220211205235.2089104-1-andrii@kernel.org
      d130e954
    • Andrii Nakryiko's avatar
      Merge branch 'bpftool: Switch to new versioning scheme (align on libbpf's)' · 4407fa06
      Andrii Nakryiko authored
      Quentin Monnet says:
      
      ====================
      
      Hi, this set aims at updating the way bpftool versions are numbered.
      Instead of copying the version from the kernel (given that the sources for
      the kernel and bpftool are shipped together), align it on libbpf's version
      number, with a fixed offset (6) to avoid going backwards. Please refer to
      the description of the second commit for details on the motivations.
      
      The patchset also adds the number of the version of libbpf that was used to
      compile to the output of "bpftool version". Bpftool makes such a heavy
      usage of libbpf that it makes sense to indicate what version was used to
      build it.
      
      v3:
      - Compute bpftool's version at compile time, but from the macros exposed by
        libbpf instead of calling a shell to compute $(BPFTOOL_VERSION) in the
        Makefile.
      - Drop the commit which would add a "libbpfversion" target to libbpf's
        Makefile. This is no longer necessary.
      - Use libbpf's major, minor versions with jsonw_printf() to avoid
        offsetting the version string to skip the "v" prefix.
      - Reword documentation change.
      
      v2:
      - Align on libbpf's version number instead of creating an independent
        versioning scheme.
      - Use libbpf_version_string() to retrieve and display libbpf's version.
      - Re-order patches (1 <-> 2).
      ====================
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      4407fa06
    • Quentin Monnet's avatar
      bpftool: Update versioning scheme, align on libbpf's version number · 9910a74d
      Quentin Monnet authored
      Since the notion of versions was introduced for bpftool, it has been
      following the version number of the kernel (using the version number
      corresponding to the tree in which bpftool's sources are located). The
      rationale was that bpftool's features are loosely tied to BPF features
      in the kernel, and that we could defer versioning to the kernel
      repository itself.
      
      But this versioning scheme is confusing today, because a bpftool binary
      should be able to work with both older and newer kernels, even if some
      of its recent features won't be available on older systems. Furthermore,
      if bpftool is ported to other systems in the future, keeping a
      Linux-based version number is not a good option.
      
      Looking at other options, we could either have a totally independent
      scheme for bpftool, or we could align it on libbpf's version number
      (with an offset on the major version number, to avoid going backwards).
      The latter comes with a few drawbacks:
      
      - We may want bpftool releases in-between two libbpf versions. We can
        always append pre-release numbers to distinguish versions, although
        those won't look as "official" as something with a proper release
        number. But at the same time, having bpftool with version numbers that
        look "official" hasn't really been an issue so far.
      
      - If no new feature lands in bpftool for some time, we may move from
        e.g. 6.7.0 to 6.8.0 when libbpf levels up and have two different
        versions which are in fact the same.
      
      - Following libbpf's versioning scheme sounds better than kernel's, but
        ultimately it doesn't make too much sense either, because even though
        bpftool uses the lib a lot, its behaviour is not that much conditioned
        by the internal evolution of the library (or by new APIs that it may
        not use).
      
      Having an independent versioning scheme solves the above, but at the
      cost of heavier maintenance. Developers will likely forget to increase
      the numbers when adding features or bug fixes, and we would take the
      risk of having to send occasional "catch-up" patches just to update the
      version number.
      
      Based on these considerations, this patch aligns bpftool's version
      number on libbpf's. This is not a perfect solution, but 1) it's
      certainly an improvement over the current scheme, 2) the issues raised
      above are all minor at the moment, and 3) we can still move to an
      independent scheme in the future if we realise we need it.
      
      Given that libbpf is currently at version 0.7.0, and bpftool, before
      this patch, was at 5.16, we use an offset of 6 for the major version,
      bumping bpftool to 6.7.0. Libbpf does not export its patch number;
      leave bpftool's patch number at 0 for now.
      
      It remains possible to manually override the version number by setting
      BPFTOOL_VERSION when calling make.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220210104237.11649-3-quentin@isovalent.com
      9910a74d
    • Quentin Monnet's avatar
      bpftool: Add libbpf's version number to "bpftool version" output · 61fce969
      Quentin Monnet authored
      To help users check what version of libbpf is being used with bpftool,
      print the number along with bpftool's own version number.
      
      Output:
      
          $ ./bpftool version
          ./bpftool v5.16.0
          using libbpf v0.7
          features: libbfd, libbpf_strict, skeletons
      
          $ ./bpftool version --json --pretty
          {
              "version": "5.16.0",
              "libbpf_version": "0.7",
              "features": {
                  "libbfd": true,
                  "libbpf_strict": true,
                  "skeletons": true
              }
          }
      
      Note that libbpf does not expose its patch number.
      Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
      Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
      Link: https://lore.kernel.org/bpf/20220210104237.11649-2-quentin@isovalent.com
      61fce969
    • Song Liu's avatar
      bpf: Fix bpf_prog_pack build for ppc64_defconfig · 4cc0991a
      Song Liu authored
      bpf_prog_pack causes build error with powerpc ppc64_defconfig:
      
      kernel/bpf/core.c:830:23: error: variably modified 'bitmap' at file scope
        830 |         unsigned long bitmap[BITS_TO_LONGS(BPF_PROG_CHUNK_COUNT)];
            |                       ^~~~~~
      
      This is because the marco expands as:
      
      unsigned long bitmap[((((((1UL) << (16 + __pte_index_size)) / (1 << 6))) \
           + ((sizeof(long) * 8)) - 1) / ((sizeof(long) * 8)))];
      
      where __pte_index_size is a global variable.
      
      Fix it by turning bitmap into a 0-length array.
      
      Fixes: 57631054 ("bpf: Introduce bpf_prog_pack allocator")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarSong Liu <song@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220211024939.2962537-1-song@kernel.org
      4cc0991a
    • Lorenzo Bianconi's avatar
      selftest/bpf: Check invalid length in test_xdp_update_frags · a5a358ab
      Lorenzo Bianconi authored
      Update test_xdp_update_frags adding a test for a buffer size
      set to (MAX_SKB_FRAGS + 2) * PAGE_SIZE. The kernel is supposed
      to return -ENOMEM.
      Signed-off-by: default avatarLorenzo Bianconi <lorenzo@kernel.org>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Acked-by: default avatarYonghong Song <yhs@fb.com>
      Link: https://lore.kernel.org/bpf/3e4afa0ee4976854b2f0296998fe6754a80b62e5.1644366736.git.lorenzo@kernel.org
      a5a358ab
  5. 10 Feb, 2022 24 commits