From: Andrii Nakryiko <andrii@kernel.org>
To: <bpf@vger.kernel.org>, <ast@kernel.org>, <daniel@iogearbox.net>
Cc: <andrii@kernel.org>, <kernel-team@fb.com>
Subject: [PATCH v3 bpf-next 0/9] libbpf: stricter BPF program section name handling
Date: Wed, 22 Sep 2021 16:41:04 -0700 [thread overview]
Message-ID: <20210922234113.1965663-1-andrii@kernel.org> (raw)
Implement opt-in stricter BPF program section name (SEC()) handling logic. For
a lot of supported ELF section names, enforce exact section name match with no
arbitrary characters added at the end. See patch #8 for more details.
To allow this, first three patches clean up and preventively fix selftests,
normalizing existing SEC() usage across multiple selftests. While at it those
patches also reduce the amount of remaining bpf_object__find_program_by_title()
uses, which should be completely removed soon, given it's an API with
ambiguous semantics and will be deprecated and eventually removed in libbpf 1.0.
Last patch is also fixing "sk_lookup/" definition to not require and not allow
extra "/blah" parts after it, which serve no meaning.
All the other patches are gradual internal libbpf changes to:
- allow this optional strict logic for ELF section name handling;
- allow new use case (for now for "struct_ops", but that could be extended
to, say, freplace definitions), in which it can be used stand-alone to
specify just type (SEC("struct_ops")), or also accept extra parameters
which can be utilized by libbpf to either get more data or double-check
valid use (e.g., SEC("struct_ops/dctcp_init") to specify desired
struct_ops operation that is supposed to be implemented);
- get libbpf's internal logic ready to allow other libraries and
applications to specify their custom handlers for ELF section name for BPF
programs. All the pieces are in place, the only thing preventing making
this as public libbpf API is reliance on internal type for specifying BPF
program load attributes. The work is planned to revamp related low-level
libbpf APIs, at which point it will be possible to just re-use such new
types for coordination between libbpf and custom handlers.
These changes are a part of libbpf 1.0 effort ([0]). They are also intended to
be applied on top of the previous preparatory series [1], so currently CI will
be failing to apply them to bpf-next until that patch set is landed. Once it
is landed, kernel-patches daemon will automatically retest this patch set.
[0] https://github.com/libbpf/libbpf/wiki/Libbpf:-the-road-to-v1.0#stricter-and-more-uniform-bpf-program-section-name-sec-handling
[1] https://patchwork.kernel.org/project/netdevbpf/list/?series=547675&state=*
v2->v3:
- applied acks, addressed most feedback, added comments to new flags (Dave);
v1->v2:
- rebase onto latest bpf-next and resolve merge conflicts w/ Dave's changes.
Andrii Nakryiko (9):
selftests/bpf: normalize XDP section names in selftests
selftests/bpf: normalize SEC("classifier") usage
selftests/bpf: normalize all the rest SEC() uses
libbpf: refactor internal sec_def handling to enable pluggability
libbpf: reduce reliance of attach_fns on sec_def internals
libbpf: refactor ELF section handler definitions
libbpf: complete SEC() table unification for
BPF_APROG_SEC/BPF_EAPROG_SEC
libbpf: add opt-in strict BPF program section name handling logic
selftests/bpf: switch sk_lookup selftests to strict SEC("sk_lookup")
use
tools/lib/bpf/libbpf.c | 517 +++++++++---------
tools/lib/bpf/libbpf_internal.h | 7 +
tools/lib/bpf/libbpf_legacy.h | 9 +
.../selftests/bpf/prog_tests/flow_dissector.c | 4 +-
.../bpf/prog_tests/reference_tracking.c | 23 +-
.../selftests/bpf/prog_tests/sk_assign.c | 2 +-
.../selftests/bpf/prog_tests/sockopt_multi.c | 30 +-
.../selftests/bpf/prog_tests/tailcalls.c | 58 +-
tools/testing/selftests/bpf/progs/bpf_flow.c | 3 +-
.../bpf/progs/cg_storage_multi_isolated.c | 4 +-
.../bpf/progs/cg_storage_multi_shared.c | 4 +-
.../testing/selftests/bpf/progs/skb_pkt_end.c | 2 +-
.../selftests/bpf/progs/sockopt_multi.c | 5 +-
tools/testing/selftests/bpf/progs/tailcall1.c | 5 +-
tools/testing/selftests/bpf/progs/tailcall2.c | 21 +-
tools/testing/selftests/bpf/progs/tailcall3.c | 5 +-
tools/testing/selftests/bpf/progs/tailcall4.c | 5 +-
tools/testing/selftests/bpf/progs/tailcall5.c | 5 +-
tools/testing/selftests/bpf/progs/tailcall6.c | 4 +-
.../selftests/bpf/progs/tailcall_bpf2bpf1.c | 5 +-
.../selftests/bpf/progs/tailcall_bpf2bpf2.c | 5 +-
.../selftests/bpf/progs/tailcall_bpf2bpf3.c | 9 +-
.../selftests/bpf/progs/tailcall_bpf2bpf4.c | 13 +-
.../bpf/progs/test_btf_skc_cls_ingress.c | 2 +-
.../selftests/bpf/progs/test_cgroup_link.c | 4 +-
.../selftests/bpf/progs/test_cls_redirect.c | 2 +-
.../selftests/bpf/progs/test_global_data.c | 2 +-
.../selftests/bpf/progs/test_global_func1.c | 2 +-
.../selftests/bpf/progs/test_global_func3.c | 2 +-
.../selftests/bpf/progs/test_global_func5.c | 2 +-
.../selftests/bpf/progs/test_global_func6.c | 2 +-
.../selftests/bpf/progs/test_global_func7.c | 2 +-
.../selftests/bpf/progs/test_map_in_map.c | 2 +-
.../bpf/progs/test_misc_tcp_hdr_options.c | 2 +-
.../selftests/bpf/progs/test_pkt_access.c | 2 +-
.../selftests/bpf/progs/test_pkt_md_access.c | 4 +-
.../selftests/bpf/progs/test_sk_assign.c | 3 +-
.../selftests/bpf/progs/test_sk_lookup.c | 44 +-
.../selftests/bpf/progs/test_sk_lookup_kern.c | 37 +-
.../selftests/bpf/progs/test_skb_helpers.c | 2 +-
.../selftests/bpf/progs/test_sockmap_listen.c | 2 +-
.../progs/test_sockmap_skb_verdict_attach.c | 2 +-
.../selftests/bpf/progs/test_sockmap_update.c | 2 +-
.../selftests/bpf/progs/test_tc_neigh.c | 6 +-
.../selftests/bpf/progs/test_tc_neigh_fib.c | 6 +-
.../selftests/bpf/progs/test_tc_peer.c | 10 +-
.../bpf/progs/test_tcp_check_syncookie_kern.c | 4 +-
.../bpf/progs/test_tcp_hdr_options.c | 2 +-
tools/testing/selftests/bpf/progs/test_xdp.c | 2 +-
.../bpf/progs/test_xdp_adjust_tail_grow.c | 2 +-
.../bpf/progs/test_xdp_adjust_tail_shrink.c | 4 +-
.../bpf/progs/test_xdp_devmap_helpers.c | 2 +-
.../selftests/bpf/progs/test_xdp_link.c | 2 +-
.../selftests/bpf/progs/test_xdp_loop.c | 2 +-
.../selftests/bpf/progs/test_xdp_noinline.c | 4 +-
.../bpf/progs/test_xdp_with_cpumap_helpers.c | 4 +-
.../bpf/progs/test_xdp_with_devmap_helpers.c | 4 +-
tools/testing/selftests/bpf/progs/xdp_dummy.c | 2 +-
.../bpf/progs/xdp_redirect_multi_kern.c | 4 +-
.../testing/selftests/bpf/progs/xdping_kern.c | 4 +-
.../selftests/bpf/test_tcp_check_syncookie.sh | 4 +-
.../selftests/bpf/test_xdp_redirect.sh | 4 +-
.../selftests/bpf/test_xdp_redirect_multi.sh | 2 +-
tools/testing/selftests/bpf/test_xdp_veth.sh | 4 +-
tools/testing/selftests/bpf/xdping.c | 5 +-
65 files changed, 473 insertions(+), 477 deletions(-)
--
2.30.2
next reply other threads:[~2021-09-22 23:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-22 23:41 Andrii Nakryiko [this message]
2021-09-22 23:41 ` [PATCH v3 bpf-next 1/9] selftests/bpf: normalize XDP section names in selftests Andrii Nakryiko
2021-09-22 23:41 ` [PATCH v3 bpf-next 2/9] selftests/bpf: normalize SEC("classifier") usage Andrii Nakryiko
2021-09-23 16:52 ` Dave Marchevsky
2021-09-27 15:14 ` Daniel Borkmann
2021-09-27 16:12 ` Alexei Starovoitov
2021-09-28 1:53 ` Andrii Nakryiko
2021-09-22 23:41 ` [PATCH v3 bpf-next 3/9] selftests/bpf: normalize all the rest SEC() uses Andrii Nakryiko
2021-09-22 23:41 ` [PATCH v3 bpf-next 4/9] libbpf: refactor internal sec_def handling to enable pluggability Andrii Nakryiko
2021-09-22 23:41 ` [PATCH v3 bpf-next 5/9] libbpf: reduce reliance of attach_fns on sec_def internals Andrii Nakryiko
2021-09-22 23:41 ` [PATCH v3 bpf-next 6/9] libbpf: refactor ELF section handler definitions Andrii Nakryiko
2021-09-23 17:21 ` Dave Marchevsky
2021-09-22 23:41 ` [PATCH v3 bpf-next 7/9] libbpf: complete SEC() table unification for BPF_APROG_SEC/BPF_EAPROG_SEC Andrii Nakryiko
2021-09-23 20:41 ` Dave Marchevsky
2021-09-22 23:41 ` [PATCH v3 bpf-next 8/9] libbpf: add opt-in strict BPF program section name handling logic Andrii Nakryiko
2021-09-23 16:43 ` Dave Marchevsky
2021-09-22 23:41 ` [PATCH v3 bpf-next 9/9] selftests/bpf: switch sk_lookup selftests to strict SEC("sk_lookup") use Andrii Nakryiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210922234113.1965663-1-andrii@kernel.org \
--to=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=kernel-team@fb.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).