netdev - Re: [PATCH bpf-next v3 2/3] libbpf: add bpf_object__load_xattr() API function to pass log

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]

Message-ID: <0842db21-996b-346c-d572-e7384802eae0@netronome.com>
Date:   Fri, 24 May 2019 16:15:22 +0100
From:   Quentin Monnet <quentin.monnet@...ronome.com>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
Cc:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>, bpf@...r.kernel.org,
        netdev@...r.kernel.org, oss-drivers@...ronome.com,
        Yonghong Song <yhs@...com>, Andrii Nakryiko <andriin@...com>
Subject: Re: [PATCH bpf-next v3 2/3] libbpf: add bpf_object__load_xattr() API
 function to pass log_level

2019-05-24 14:49 UTC+0200 ~ Jesper Dangaard Brouer <brouer@...hat.com>
> On Fri, 24 May 2019 12:51:14 +0100
> Quentin Monnet <quentin.monnet@...ronome.com> wrote:
> 
>> 2019-05-24 13:22 UTC+0200 ~ Jesper Dangaard Brouer <brouer@...hat.com>
>>> On Fri, 24 May 2019 11:36:47 +0100
>>> Quentin Monnet <quentin.monnet@...ronome.com> wrote:
>>>   
>>>> libbpf was recently made aware of the log_level attribute for programs,
>>>> used to specify the level of information expected to be dumped by the
>>>> verifier. Function bpf_prog_load_xattr() got support for this log_level
>>>> parameter.
>>>>
>>>> But some applications using libbpf rely on another function to load
>>>> programs, bpf_object__load(), which does accept any parameter for log
>>>> level. Create an API function based on bpf_object__load(), but accepting
>>>> an "attr" object as a parameter. Then add a log_level field to that
>>>> object, so that applications calling the new bpf_object__load_xattr()
>>>> can pick the desired log level.  
>>>
>>> Does this allow us to extend struct bpf_object_load_attr later?  
>>
>> I see no reason why it could not. Having the _xattr() version of the
>> function is precisely a way to have something extensible in the future,
>> without having to create additional API functions each time we want to
>> pass a new parameter. And e.g. struct bpf_prog_load_attr (used with
>> bpf_prog_load_xattr()) has already been extended in the past. So, yeah,
>> we can add to it in the future.
> 
> Great.  I just don't know/understand how user-space handle this. If a
> binary is compiled with libbpf as dynamic loadable lib, then it e.g. saw
> libbpf.so.2 when it was compiled, then can't it choose to use libbpf.so.3
> then? (e.g. when libbpf.so.2 is not on the system). (I would actually
> like to learn/understand this, so links are welcome).

Well I'm no library expert, so don't take my word for it. As far as I
understand, the soname of the library is selected at link time. So if
your app is linked again libbpf.so.2, you will need version 2.* of the
library to be installed on your system, because increasing the version
number usually implies ABI breakage. You can usually check which version
of the libraries is needed with ldd ("ldd bpftool", except that you
won't see libbpf because it's statically linked for bpftool).

This being said, for now the version number for libbpf has not been
incremented and is still at 0, we only had the extraversion increasing.
Since it's not part of the soname ("-Wl,-soname,libbpf.so.$(VERSION)" in
libbpf Makefile), it is not taken into account when searching for the
lib on the system. What I mean is that if the program is linked against
libbpf.so.0, it could pick libbpf.so.0.0.2 or libbpf.so.0.0.3
indifferently depending on what it finds on the system (I assume it
takes the newest?). There should not be any ABI breakage between the
two, so programs compiled against an older patchlevel or extraversion of
the library should still be able to use a newer one.

There is some documentation on libraries here (I should take some time
to finish reading it myself!):

http://tldp.org/HOWTO/Program-Library-HOWTO/

There are also interesting elements in the documentation that was cited
when Andrey introduced the LIBPPF_API macros in libbpf:

https://www.akkadia.org/drepper/dsohowto.pdf

> 
>> Do you have something in mind?
> 
> I was playing with extending bpf_prog_load_attr, but instead I created a
> bpf_prog_load_attr_maps instead and a new function
> bpf_prog_load_xattr_maps(), e.g. see:
> 
> https://github.com/xdp-project/xdp-tutorial/blob/master/common/common_libbpf.h
> https://github.com/xdp-project/xdp-tutorial/blob/master/common/common_libbpf.c
> 
> I guess, I could just extend bpf_prog_load_attr instead, right?
> 

I believe so.

Best,
Quentin