netdev - Re: bpf libraries and static variables. Was: [PATCH v2 bpf-next 2/6] libbpf: rename static variables during 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, 13 May 2021 09:37:13 +0100
From:   Lorenz Bauer <lmb@...udflare.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andrii@...nel.org>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>,
        John Fastabend <john.fastabend@...il.com>
Subject: Re: bpf libraries and static variables. Was: [PATCH v2 bpf-next 2/6]
 libbpf: rename static variables during linking

On Wed, 12 May 2021 at 19:50, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
>

...

> So at least for BPF skeleton, the flow I was imagining would be
> like this.

Thank you for the worked out example, it's really helpful.

>
> 1. BPF library abc consists of abc1.bpf.c and abc2.bpf.c. It also has
> user-space component in abc.c.
> 2. BPF app uses abs library and has its own app1.bpf.c and app2.bpf.c
> and app.c for user-space.
> 3. BPF library author sets up its Makefile to do
>   a. clang -target bpf -g -O2 -c abc1.bpf.c -o abc1.bpf.o
>   b. clang -target bpf -g -O2 -c abc2.bpf.c -o abc2.bpf.o
>   c. bpftool gen lib libabc.bpf.o abc1.bpf.o abc2.bpf.o

I think we can plug this into bpf2go [1] on our side in the best case,
which would avoid duplicating the static linker.

>   d. bpftool gen subskeleton libabc.bpf.o > libabc.subskel.h
>   e. abc.c (user-space library) is of the form
>
> #include "libabc.subskel.h"
>
> static struct libabc_bpf *subskel;
>
> int libabc__init(struct bpf_object *obj)
> {
>     subskel = libabc_bpf__open_subskel(obj);
>
>     subskel->data->abc_my_var = 123;
> }
>
> int libabc__attach()
> {
>     libabc_bpf__attach(subskel);
> }
>
>   f. cc abc.c into libabc.a and then libabc.a and libabc.bpf.o are
> distributed to end user
>
> 3. Now, from BPF application author side:
>   a. clang -target bpf -g -O2 -c app1.bpf.c -o app1.bpf.o
>   b. clang -target bpf -g -O2 -c app2.bpf.c -o app2.bpf.o
>   c. bpftool gen object app.bpf.o app1.bpf.o app2.bpf.o libabc.bpf.o

I haven't worked out exactly how things would work, but on the Go side
it might be possible to distribute libabc.bpf.o plus the Go "library"
code as a package. So the Go toolchain would never create this merged
object, but instead do

    bpftool gen object app.bpf.o app1.bpf.o app2.bpf.o

and later link app.bpf.o and libabc.bpf.o at runtime. It would be
simpler from our side if bpftool gen object could link both libraries
and "programs", maybe we can discuss the details of this during office
hours.

1: https://pkg.go.dev/github.com/cilium/ebpf/cmd/bpf2go

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com