netdev - Re: [PATCH v4 bpf-next 00/12] BPF static linking

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 18 Mar 2021 16:29:27 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andrii@...nel.org>
Cc:     bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v4 bpf-next 00/12] BPF static linking

On Thu, Mar 18, 2021 at 12:42 PM Andrii Nakryiko <andrii@...nel.org> wrote:
>
> This patch set adds new libbpf APIs and their bpftool integration that allows
> to perform static linking of BPF object files. Currently no extern resolution
> across object files is performed. This is going to be the focus of the follow
> up patches. But, given amount of code and logic necessary to perform just
> basic functionality of linking together mostly independent BPF object files,
> it was decided to land basic BPF linker code and logic first and extend it
> afterwards.
>
> The motivation for BPF static linking is to provide the functionality that is
> naturally assumed for user-space development process: ability to structure
> application's code without artificial restrictions of having all the code and
> data (variables and maps) inside a single source code file.
>
> This enables better engineering practices of splitting code into
> well-encapsulated parts. It provides ability to hide internal state from other
> parts of the code base through static variables and maps. It is also a first
> steps towards having generic reusable BPF libraries.
>
> Please see individual patches (mostly #6 and #7) for more details. Patch #10
> passes all test_progs' individual BPF .o files through BPF static linker,
> which is supposed to be a no-op operation, so is essentially validating that
> BPF static linker doesn't produce corrupted ELF object files. Patch #11 adds
> Makefile infra to be able to specify multi-file BPF object files and adds the
> first multi-file test to validate correctness.
>
> v3->v4:
>   - fix Makefile copy/paste error of diff'ing invalid object files (Alexei);
>   - fix uninitialized obj_name variable that could lead to bogus object names
>     being used during skeleton generation (kernel-patches CI);

Applied.