netdev - [PATCH RFC bpf-next 0/3] libbpf: Add support for extern function calls

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <157676577049.957277.3346427306600998172.stgit@toke.dk>
Date:   Thu, 19 Dec 2019 15:29:30 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
        bpf@...r.kernel.org
Subject: [PATCH RFC bpf-next 0/3] libbpf: Add support for extern function
 calls

This series adds support for resolving function calls to functions marked as
'extern' in eBPF source files, by resolving the function call targets at load
time. For now, this only works by static linking (i.e., copying over the
instructions from the function target. Once the kernel support for dynamic
linking lands, support can be added for having a function target be an already
loaded program fd instead of a bpf object.

The API I'm proposing for this is that the caller specifies an explicit mapping
between extern function names and function names in the target object file.
This is to support the XDP multi-prog case, where the dispatcher program may not
necessarily have control over function names in the target programs, so simple
function name resolution can't be used.

I'm sending this series as an RFC because it's still a bit rough around the
edges: There are several places where I'm handling things in a way I'm pretty
sure is not the right way. And while this works for the simple programs added to
the selftest in patch 3, it fails with more complicated target programs.

My problem is that I don't really know what the right thing to do is for these
things, so I've marked them with FIXME comments in the code, in the hope that
someone more knowledgeable can suggest fixes.

Other regular RFC comments are welcome as well, of course; the API in particular
could use a second set of eyes or two :)

---

Toke Høiland-Jørgensen (3):
      libbpf: Add new bpf_object__load2() using new-style opts
      libbpf: Handle function externs and support static linking
      selftests/bpf: Add selftest for XDP multiprogs

 tools/lib/bpf/btf.c                                |   10 +
 tools/lib/bpf/libbpf.c                             |  299 ++++++++++++++++----
 tools/lib/bpf/libbpf.h                             |   28 ++
 tools/lib/bpf/libbpf.map                           |    1 
 .../selftests/bpf/prog_tests/xdp_multiprog.c       |   52 +++
 tools/testing/selftests/bpf/progs/xdp_drop.c       |   13 +
 tools/testing/selftests/bpf/progs/xdp_multiprog.c  |   26 ++
 7 files changed, 366 insertions(+), 63 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/xdp_multiprog.c
 create mode 100644 tools/testing/selftests/bpf/progs/xdp_drop.c
 create mode 100644 tools/testing/selftests/bpf/progs/xdp_multiprog.c