netdev - Re: Establishing /usr/lib/bpf as a convention for eBPF bytecode files?

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]

Date:   Mon, 9 Dec 2019 17:40:19 -0800
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     bpf@...r.kernel.org, Jiri Olsa <jolsa@...hat.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        daniel@...earbox.net, netdev@...r.kernel.org
Subject: Re: Establishing /usr/lib/bpf as a convention for eBPF bytecode
 files?

On Mon, Dec 09, 2019 at 12:29:27PM +0100, Toke Høiland-Jørgensen wrote:
> Hi everyone
> 
> As you have no doubt noticed, we have started thinking about how to
> package eBPF-related applications in distributions. As a part of this,
> I've been thinking about what to recommend for applications that ship
> pre-compiled BPF byte-code files.
> 
> The obvious place to place those would be somewhere in the system
> $LIBDIR (i.e., /usr/lib or /usr/lib64, depending on the distro). But
> since BPF byte code is its own binary format, different from regular
> executables, I think having a separate path to put those under makes
> sense. So I'm proposing to establish a convention that pre-compiled BPF
> programs be installed into /usr/lib{,64}/bpf.
> 
> This would let users discover which BPF programs are shipped on their
> system, and it could be used to discover which package loaded a
> particular BPF program, by walking the directory to find the file a
> loaded program came from. It would not work for dynamically-generated
> bytecode, of course, but I think at least some applications will end up
> shipping pre-compiled bytecode files (we're doing that for xdp-tools,
> for instance).
> 
> As I said, this would be a convention. We're already using it for
> xdp-tools[0], so my plan is to use that as the "first mover", try to get
> distributions to establish the path as a part of their filesystem
> layout, and then just try to encourage packages to use it. Hopefully it
> will catch on.
> 
> Does anyone have any objections to this? Do you think it is a complete
> waste of time, or is it worth giving it a shot? :)

What will be the name of file/directory ?
What is going to be the mechanism to clean it up?
What will be stored in there? Just .o files ?

libbcc stores original C and rewritten C in /var/tmp/bcc/bpf_prog_TAG/
It was useful for debugging. Since TAG is used as directory name
reloading the same bcc script creates the same dir and /var/tmp
periodically gets cleaned by reboot.

Installing bpf .o into common location feels useful. Not sure though
how you can convince folks to follow such convention.
That was the main problem with libbcc. Not everything is using that lib.
So teaching folks who debug bpf in production to look into /var/tmp/bcc
wasn't enough. 'bpftool p s' is still the main mechanism.
Some C++ services embed bpf .o as part of x86 binary and that binary
is installed. They wouldn't want to split bpf .o into separate file
since it will complicate dependency management, risk conflicts, etc.
Just food for thought.