Changes in libbpf_common.h

7f7c4369 - libbpf: Fix potential uninitialized tail padding with LIBBPF_OPTS_RESET

Tue, 07 Nov 2023 20:15:11 +0000

libbpf: Fix potential uninitialized tail padding with LIBBPF_OPTS_RESETMartin reported that there is a libbpf complaining of non-zero-value tailpadding with LIBBPF_OPTS_RESET macro if struct bpf_netkit_opts is modifiedto have a 4-byte tail padding. This only happens to clang compiler.The commend line is: ./test_progs -t tc_netkit_multi_linksMartin and I did some investigation and found this indeed the case andthe following are the investigation details.Clang: clang version 18.0.0 tools/lib/bpf/libbpf_common.h: #define LIBBPF_OPTS_RESET(NAME, ...) \ do { \ memset(&NAME, 0, sizeof(NAME)); \ NAME = (typeof(NAME)) { \ .sz = sizeof(NAME), \ __VA_ARGS__ \ }; \ } while (0) #endiftools/lib/bpf/libbpf.h: struct bpf_netkit_opts { /* size of this struct, for forward/backward compatibility */ size_t sz; __u32 flags; __u32 relative_fd; __u32 relative_id; __u64 expected_revision; size_t :0; }; #define bpf_netkit_opts__last_field expected_revisionIn the above struct bpf_netkit_opts, there is no tail padding.prog_tests/tc_netkit.c: static void serial_test_tc_netkit_multi_links_target(int mode, int target) { ... LIBBPF_OPTS(bpf_netkit_opts, optl); ... LIBBPF_OPTS_RESET(optl, .flags = BPF_F_BEFORE, .relative_fd = bpf_program__fd(skel->progs.tc1), ); ... }Let us make the following source change, note that we have a 4-bytetailing padding now. diff --git a/tools/lib/bpf/libbpf.h b/tools/lib/bpf/libbpf.h index 6cd9c501624f..0dd83910ae9a 100644 --- a/tools/lib/bpf/libbpf.h +++ b/tools/lib/bpf/libbpf.h @@ -803,13 +803,13 @@ bpf_program__attach_tcx(const struct bpf_program *prog, int ifindex, struct bpf_netkit_opts { /* size of this struct, for forward/backward compatibility */ size_t sz; - __u32 flags; __u32 relative_fd; __u32 relative_id; __u64 expected_revision; + __u32 flags; size_t :0; }; -#define bpf_netkit_opts__last_field expected_revision +#define bpf_netkit_opts__last_field flagsThe clang 18 generated asm code looks like below: ; LIBBPF_OPTS_RESET(optl, 55e3: 48 8d 7d 98 leaq -0x68(%rbp), %rdi 55e7: 31 f6 xorl %esi, %esi 55e9: ba 20 00 00 00 movl $0x20, %edx 55ee: e8 00 00 00 00 callq 0x55f3 55f3: 48 c7 85 10 fd ff ff 20 00 00 00 movq $0x20, -0x2f0(%rbp) 55fe: 48 8b 85 68 ff ff ff movq -0x98(%rbp), %rax 5605: 48 8b 78 18 movq 0x18(%rax), %rdi 5609: e8 00 00 00 00 callq 0x560e 560e: 89 85 18 fd ff ff movl %eax, -0x2e8(%rbp) 5614: c7 85 1c fd ff ff 00 00 00 00 movl $0x0, -0x2e4(%rbp) 561e: 48 c7 85 20 fd ff ff 00 00 00 00 movq $0x0, -0x2e0(%rbp) 5629: c7 85 28 fd ff ff 08 00 00 00 movl $0x8, -0x2d8(%rbp) 5633: 48 8b 85 10 fd ff ff movq -0x2f0(%rbp), %rax 563a: 48 89 45 98 movq %rax, -0x68(%rbp) 563e: 48 8b 85 18 fd ff ff movq -0x2e8(%rbp), %rax 5645: 48 89 45 a0 movq %rax, -0x60(%rbp) 5649: 48 8b 85 20 fd ff ff movq -0x2e0(%rbp), %rax 5650: 48 89 45 a8 movq %rax, -0x58(%rbp) 5654: 48 8b 85 28 fd ff ff movq -0x2d8(%rbp), %rax 565b: 48 89 45 b0 movq %rax, -0x50(%rbp) ; link = bpf_program__attach_netkit(skel->progs.tc2, ifindex, &optl);At -O0 level, the clang compiler creates an intermediate copy.We have below to store 'flags' with 4-byte store and leave another 4 bytein the same 8-byte-aligned storage undefined, 5629: c7 85 28 fd ff ff 08 00 00 00 movl $0x8, -0x2d8(%rbp)and later we store 8-byte to the original zero'ed buffer 5654: 48 8b 85 28 fd ff ff movq -0x2d8(%rbp), %rax 565b: 48 89 45 b0 movq %rax, -0x50(%rbp)This caused a problem as the 4-byte value at [%rbp-0x2dc, %rbp-0x2e0)may be garbage.gcc (gcc 11.4) does not have this issue as it does zeroing struct first beforedoing assignments: ; LIBBPF_OPTS_RESET(optl, 50fd: 48 8d 85 40 fc ff ff leaq -0x3c0(%rbp), %rax 5104: ba 20 00 00 00 movl $0x20, %edx 5109: be 00 00 00 00 movl $0x0, %esi 510e: 48 89 c7 movq %rax, %rdi 5111: e8 00 00 00 00 callq 0x5116 5116: 48 8b 45 f0 movq -0x10(%rbp), %rax 511a: 48 8b 40 18 movq 0x18(%rax), %rax 511e: 48 89 c7 movq %rax, %rdi 5121: e8 00 00 00 00 callq 0x5126 5126: 48 c7 85 40 fc ff ff 00 00 00 00 movq $0x0, -0x3c0(%rbp) 5131: 48 c7 85 48 fc ff ff 00 00 00 00 movq $0x0, -0x3b8(%rbp) 513c: 48 c7 85 50 fc ff ff 00 00 00 00 movq $0x0, -0x3b0(%rbp) 5147: 48 c7 85 58 fc ff ff 00 00 00 00 movq $0x0, -0x3a8(%rbp) 5152: 48 c7 85 40 fc ff ff 20 00 00 00 movq $0x20, -0x3c0(%rbp) 515d: 89 85 48 fc ff ff movl %eax, -0x3b8(%rbp) 5163: c7 85 58 fc ff ff 08 00 00 00 movl $0x8, -0x3a8(%rbp) ; link = bpf_program__attach_netkit(skel->progs.tc2, ifindex, &optl);It is not clear how to resolve the compiler code generation as the compilergenerates correct code w.r.t. how to handle unnamed padding in C standard.So this patch changed LIBBPF_OPTS_RESET macro to avoid uninitialized tailpadding. We already knows LIBBPF_OPTS macro works on both gcc and clang,even with tail padding. So LIBBPF_OPTS_RESET is changed to be aLIBBPF_OPTS followed by a memcpy(), thus avoiding uninitialized tail padding.The below is asm code generated with this patch and with clang compiler: ; LIBBPF_OPTS_RESET(optl, 55e3: 48 8d bd 10 fd ff ff leaq -0x2f0(%rbp), %rdi 55ea: 31 f6 xorl %esi, %esi 55ec: ba 20 00 00 00 movl $0x20, %edx 55f1: e8 00 00 00 00 callq 0x55f6 55f6: 48 c7 85 10 fd ff ff 20 00 00 00 movq $0x20, -0x2f0(%rbp) 5601: 48 8b 85 68 ff ff ff movq -0x98(%rbp), %rax 5608: 48 8b 78 18 movq 0x18(%rax), %rdi 560c: e8 00 00 00 00 callq 0x5611 5611: 89 85 18 fd ff ff movl %eax, -0x2e8(%rbp) 5617: c7 85 1c fd ff ff 00 00 00 00 movl $0x0, -0x2e4(%rbp) 5621: 48 c7 85 20 fd ff ff 00 00 00 00 movq $0x0, -0x2e0(%rbp) 562c: c7 85 28 fd ff ff 08 00 00 00 movl $0x8, -0x2d8(%rbp) 5636: 48 8b 85 10 fd ff ff movq -0x2f0(%rbp), %rax 563d: 48 89 45 98 movq %rax, -0x68(%rbp) 5641: 48 8b 85 18 fd ff ff movq -0x2e8(%rbp), %rax 5648: 48 89 45 a0 movq %rax, -0x60(%rbp) 564c: 48 8b 85 20 fd ff ff movq -0x2e0(%rbp), %rax 5653: 48 89 45 a8 movq %rax, -0x58(%rbp) 5657: 48 8b 85 28 fd ff ff movq -0x2d8(%rbp), %rax 565e: 48 89 45 b0 movq %rax, -0x50(%rbp) ; link = bpf_program__attach_netkit(skel->progs.tc2, ifindex, &optl);In the above code, a temporary buffer is zeroed and then has proper value assigned.Finally, values in temporary buffer are copied to the original variable buffer,hence tail padding is guaranteed to be 0.Signed-off-by: Yonghong Song Signed-off-by: Andrii Nakryiko Tested-by: Martin KaFai Lau Link: https://lore.kernel.org/bpf/20231107201511.2548645-1-yonghong.song@linux.devSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

4e9c2d9a - libbpf: Add helper macro to clear opts structs

Wed, 19 Jul 2023 14:08:55 +0000
libbpf: Add helper macro to clear opts structsAdd a small and generic LIBBPF_OPTS_RESET() helper macros which clears anopts structure and reinitializes its .sz member to place the structuresize. Additionally, the user can pass option-specific data to reinitializevia varargs.I found this very useful when developing selftests, but it is also genericenough as a macro next to the existing LIBBPF_OPTS() which hides the .szinitialization, too.Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/r/20230719140858.13224-6-daniel@iogearbox.netSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

a11113a2 - libbpf: cleanup LIBBPF_DEPRECATED_SINCE supporting macros for v0.x

Mon, 27 Jun 2022 21:15:22 +0000
libbpf: cleanup LIBBPF_DEPRECATED_SINCE supporting macros for v0.xKeep the LIBBPF_DEPRECATED_SINCE macro "framework" for futuredeprecations, but clean up 0.x related helper macros.Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20220627211527.2245459-11-andrii@kernel.orgSigned-off-by: Alexei Starovoitov List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

c93faaaf - libbpf: Deprecate bpf_prog_load_xattr() API

Wed, 01 Dec 2021 23:28:24 +0000
libbpf: Deprecate bpf_prog_load_xattr() APIbpf_prog_load_xattr() is high-level API that's named as a low-levelBPF_PROG_LOAD wrapper APIs, but it actually operates on structbpf_object. It's badly and confusingly misnamed as it will load all theprogs insige bpf_object, returning prog_fd of the very first BPFprogram. It also has a bunch of ad-hoc things like log_level override,map_ifindex auto-setting, etc. All this can be expressed more explicitlyand cleanly through existing libbpf APIs. This patch marksbpf_prog_load_xattr() for deprecation in libbpf v0.8 ([0]). [0] Closes: https://github.com/libbpf/libbpf/issues/308Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211201232824.3166325-10-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

d10ef2b8 - libbpf: Unify low-level BPF_PROG_LOAD APIs into bpf_prog_load()

Wed, 03 Nov 2021 22:08:36 +0000
libbpf: Unify low-level BPF_PROG_LOAD APIs into bpf_prog_load()Add a new unified OPTS-based low-level API for program loading,bpf_prog_load() ([0]). bpf_prog_load() accepts few "mandatory"parameters as input arguments (program type, name, license,instructions) and all the other optional (as in not required to specifyfor all types of BPF programs) fields into struct bpf_prog_load_opts.This makes all the other non-extensible APIs variant for BPF_PROG_LOADobsolete and they are slated for deprecation in libbpf v0.7: - bpf_load_program(); - bpf_load_program_xattr(); - bpf_verify_program().Implementation-wise, internal helper libbpf__bpf_prog_load is refactoredto become a public bpf_prog_load() API. struct bpf_prog_load_params usedinternally is replaced by public struct bpf_prog_load_opts.Unfortunately, while conceptually all this is pretty straightforward,the biggest complication comes from the already existing bpf_prog_load()*high-level* API, which has nothing to do with BPF_PROG_LOAD command.We try really hard to have a new API named bpf_prog_load(), though,because it maps naturally to BPF_PROG_LOAD command.For that, we rename old bpf_prog_load() into bpf_prog_load_deprecated()and mark it as COMPAT_VERSION() for shared library users compiledagainst old version of libbpf. Statically linked users and shared libusers compiled against new version of libbpf headers will get "rerouted"to bpf_prog_deprecated() through a macro helper that decides whether touse new or old bpf_prog_load() based on number of input arguments (see___libbpf_overload in libbpf_common.h).To test that existingbpf_prog_load()-using code compiles and works as expected, I've compiledand ran selftests as is. I had to remove (locally) selftest/bpf/Makefile-Dbpf_prog_load=bpf_prog_test_load hack because it was conflicting withthe macro-based overload approach. I don't expect anyone else to dosomething like this in practice, though. This is testing-specific way toreplace bpf_prog_load() calls with special testing variant of it, whichadds extra prog_flags value. After testing I kept this selftests hack,but ensured that we use a new bpf_prog_load_deprecated name for this.This patch also marks bpf_prog_load() and bpf_prog_load_xattr() as deprecated.bpf_object interface has to be used for working with struct bpf_program.Libbpf doesn't support loading just a bpf_program.The silver lining is that when we get to libbpf 1.0 all thesecomplication will be gone and we'll have one clean bpf_prog_load()low-level API with no backwards compatibility hackery surrounding it. [0] Closes: https://github.com/libbpf/libbpf/issues/284Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20211103220845.2676888-4-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

be80e9cd - libbpf: Rename DECLARE_LIBBPF_OPTS into LIBBPF_OPTS

Wed, 03 Nov 2021 22:08:34 +0000
libbpf: Rename DECLARE_LIBBPF_OPTS into LIBBPF_OPTSIt's confusing that libbpf-provided helper macro doesn't start withLIBBPF. Also "declare" vs "define" is confusing terminology, I can neverremember and always have to look up previous examples.Bypass both issues by renaming DECLARE_LIBBPF_OPTS into a short andclean LIBBPF_OPTS. To avoid breaking existing code, provide: #define DECLARE_LIBBPF_OPTS LIBBPF_OPTSin libbpf_legacy.h. We can decide later if we ever want to remove it orwe'll keep it forever because it doesn't add any maintainability burden.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Dave Marchevsky Link: https://lore.kernel.org/bpf/20211103220845.2676888-2-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

91b555d7 - libbpf: Schedule open_opts.attach_prog_fd deprecation since v0.7

Thu, 16 Sep 2021 01:58:35 +0000
libbpf: Schedule open_opts.attach_prog_fd deprecation since v0.7bpf_object_open_opts.attach_prog_fd makes a pretty strong assumptionthat bpf_object contains either only single freplace BPF program or allof BPF programs in BPF object are freplaces intended to replacedifferent subprograms of the same target BPF program. This seems botha bit confusing, too assuming, and limiting.We've had bpf_program__set_attach_target() API which allows morefine-grained control over this, on a per-program level. As such, markopen_opts.attach_prog_fd as deprecated starting from v0.7, so that wehave one more universal way of setting freplace targets. With previouschange to allow NULL attach_func_name argument, and especially combinedwith BPF skeleton, arguable bpf_program__set_attach_target() is a moreconvenient and explicit API as well.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20210916015836.1248906-7-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

0b46b755 - libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecations

Wed, 08 Sep 2021 21:32:26 +0000
libbpf: Add LIBBPF_DEPRECATED_SINCE macro for scheduling API deprecationsIntroduce a macro LIBBPF_DEPRECATED_SINCE(major, minor, message) to preparethe deprecation of two API functions. This macro marks functions as deprecatedwhen libbpf's version reaches the values passed as an argument.As part of this change libbpf_version.h header is added with recorded major(LIBBPF_MAJOR_VERSION) and minor (LIBBPF_MINOR_VERSION) libbpf version macros.They are now part of libbpf public API and can be relied upon by user code.libbpf_version.h is installed system-wide along other libbpf public headers.Due to this new build-time auto-generated header, in-kernel applicationsrelying on libbpf (resolve_btfids, bpftool, bpf_preload) are updated toinclude libbpf's output directory as part of a list of include search paths.Better fix would be to use libbpf's make_install target to install public APIheaders, but that clean up is left out as a future improvement. The buildchanges were tested by building kernel (with KBUILD_OUTPUT and O= specifiedexplicitly), bpftool, libbpf, selftests/bpf, and resolve_btfids builds. Noproblems were detected.Note that because of the constraints of the C preprocessor we have to writea few lines of macro magic for each version used to prepare deprecation (0.6for now).Also, use LIBBPF_DEPRECATED_SINCE() to schedule deprecation ofbtf__get_from_id() and btf__load(), which are replaced bybtf__load_from_kernel_by_id() and btf__load_into_kernel(), respectively,starting from future libbpf v0.6. This is part of libbpf 1.0 effort ([0]). [0] Closes: https://github.com/libbpf/libbpf/issues/278Co-developed-by: Quentin Monnet Co-developed-by: Andrii Nakryiko Signed-off-by: Quentin Monnet Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Link: https://lore.kernel.org/bpf/20210908213226.1871016-1-andrii@kernel.org List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

8505e870 - libbpf: Implement generalized .BTF.ext func/line info adjustment

Thu, 03 Sep 2020 20:35:33 +0000
libbpf: Implement generalized .BTF.ext func/line info adjustmentComplete multi-prog sections and multi sub-prog support in libbpf by properlyadjusting .BTF.ext's line and function information. Mark exposedbtf_ext__reloc_func_info() and btf_ext__reloc_func_info() APIs as deprecated.These APIs have simplistic assumption that all sub-programs are going to beappended to all main BPF programs, which doesn't hold in real life. It'sunlikely there are any users of this API, as it's very libbpfinternals-specific.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200903203542.15944-6-andriin@fb.com List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

fb9a98e1 - libbpf: Fix libbpf_common.h when installing libbpf through 'make install'

Tue, 17 Dec 2019 11:28:10 +0000
libbpf: Fix libbpf_common.h when installing libbpf through 'make install'This fixes two issues with the newly introduced libbpf_common.h file:- The header failed to include for the definition of memset()- The new file was not included in the install_headers rule in the MakefileBoth of these issues cause breakage when installing libbpf with 'makeinstall' and trying to use it in applications.Fixes: 544402d4b493 ("libbpf: Extract common user-facing helpers")Signed-off-by: Toke Høiland-Jørgensen Signed-off-by: Daniel Borkmann Acked-by: Yonghong Song Link: https://lore.kernel.org/bpf/20191217112810.768078-1-toke@redhat.com List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h

544402d4 - libbpf: Extract common user-facing helpers

Sat, 14 Dec 2019 01:43:29 +0000
libbpf: Extract common user-facing helpersLIBBPF_API and DECLARE_LIBBPF_OPTS are needed in many public libbpf APIheaders. Extract them into libbpf_common.h to avoid unnecessaryinterdependency between btf.h, libbpf.h, and bpf.h or code duplication.Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20191214014341.3442258-6-andriin@fb.com List of files: /linux-6.15/tools/lib/bpf/libbpf_common.h