Re: [PATCHv2 iproute2-next 0/5] iproute2: add libbpf support

[Andrii Nakryiko <andrii.nakryiko@gmail.com>]

On Thu, Oct 29, 2020 at 4:38 AM Jesper Dangaard Brouer
<brouer@redhat.com> wrote:
>
> On Wed, 28 Oct 2020 19:50:51 -0700
> Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
>
> > On Wed, Oct 28, 2020 at 7:34 PM Stephen Hemminger
> > <stephen@networkplumber.org> wrote:
> > >
> > > On Wed, 28 Oct 2020 19:27:20 -0700
> > > Andrii Nakryiko <andrii.nakryiko@gmail.com> wrote:
> > >
> > > > On Wed, Oct 28, 2020 at 7:06 PM Hangbin Liu <haliu@redhat.com> wrote:
> > > > >
> > > > > On Wed, Oct 28, 2020 at 05:02:34PM -0600, David Ahern wrote:
> > > > > > fails to compile on Ubuntu 20.10:
> > > > > >
> [...]
> > > > > You need to update libbpf to latest version.
> > > >
> > > > Why not using libbpf from submodule?
> > >
> > > Because it makes it harder for people downloading tarballs and distributions.
> >
> > Genuinely curious, making harder how exactly? When packaging sources
> > as a tarball you'd check out submodules before packaging, right?
> >
> > > Iproute2 has worked well by being standalone.
> >
> > Again, maybe I'm missing something, but what makes it not a
> > standalone, if it is using a submodule? Pahole, for instance, is using
> > libbpf through submodule and just bypasses all the problems with
> > detection of features and library availability. I haven't heard anyone
> > complaining about it made working with pahole harder in any way.
>
> I do believe you are missing something.

I don't think I got an answer how submodules make it harder for people
downloading tarballs and distributions, and the standalone-ness issue.
Your security angle is a very different aspect.

>  I guess I can be the relay for
> complains, so you will officially hear about this.  Red Hat and Fedora
> security is complaining that we are packaging a library (libbpf)
> directly into the individual packages.  They complain because in case
> of a security issue, they have to figure out to rebuild all the software
> packages that are statically compiled with this library.

They must be having nightmares already about BCC, bpftool, pahole, as
well as perf built with libbpf statically (perf on my server is, at
least). I also wonder how many other projects do use either submodules
or static linking with libraries as well.

>
> Maybe you say I don't care that Distro security teams have to do more
> work and update more packages.  Then security team says, we expect
> customers will use this library right, and if we ship it as a dynamic
> loadable (.so) file, then we can update and fix security issues in
> library without asking customers to recompile. (Notice the same story
> goes if we can update the base-image used by a container).

It's a trade off, and everyone decides for themselves where they want
to stand on this.

On the one hand, there are security folks obsessing about hypothetical
security vulnerabilities in libbpf so bad that they will need to
update libbpf overnight.

On the other hand, extra complexity for multiple users of libbpf to do
feature detection and working around the lack of some of the APIs in
libbpf due to older versions in the system. That extra complexity
might lead to more problems, bugs, vulnerabilities in the long run.

I understand the concerns and how dynamic libraries make it easier. We
can't really know for sure which of those two aspects would lead to
more pain and problems overall. I personally choose simplicity,
though.

But as I said, it's up to iproute2 folks to decide. Was just curious
about some of the claims I cited.


>
>
> --
> Best regards,
>   Jesper Dangaard Brouer
>   MSc.CS, Principal Kernel Engineer at Red Hat
>   LinkedIn: http://www.linkedin.com/in/brouer
>