netdev - Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

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: <CAEf4Bzb=FuVVw1wwLbGW1LU05heAFoUiJjm71=Qqxr+dS78qyQ@mail.gmail.com>
Date:   Tue, 24 Mar 2020 15:30:58 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Toke Høiland-Jørgensen <toke@...hat.com>,
        John Fastabend <john.fastabend@...il.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Andrey Ignatov <rdna@...com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing
 program when attaching XDP

On Tue, Mar 24, 2020 at 11:53 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Tue, 24 Mar 2020 11:57:45 +0100 Toke Høiland-Jørgensen wrote:
> > > If everyone is using libbpf, does kernel system (bpf syscall vs
> > > netlink) matter all that much?
> >
> > This argument works the other way as well, though: If libbpf can
> > abstract the subsystem differences and provide a consistent interface to
> > "the BPF world", why does BPF need to impose its own syscall API on the
> > networking subsystem?
>
> Hitting the nail on the head there, again :)
>
> Once upon a time when we were pushing for libbpf focus & unification,
> one of my main motivations was that a solid library that most people
> use give us the ability to provide user space abstractions.

Yes, but bpf_link is not a user-space abstraction only anymore. It
started that way and we quickly realized that we still will need
kernel support. Not everything can be abstracted in user-space only.
So I don't see any contradiction here, that's still libbpf focus.

>
> As much as adding new kernel interfaces "to rule them all" is fun, it
> has a real cost.

We are adding kernel interface regardless of XDP (for cgroups and
tracing, then perf_events, etc). The real point and real cost here is
to not have another duplication of same functionality just for XDP use
case. That's the real cost, not the other way around. Don't know how
to emphasize this further.

And there is very little fun involved from my side, believe it or not...