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: <87wo78pvf2.fsf@toke.dk>
Date:   Wed, 25 Mar 2020 11:42:57 +0100
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        John Fastabend <john.fastabend@...il.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        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

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Tue, Mar 24, 2020 at 12:22:47PM -0700, John Fastabend wrote:
>> > 
>> > Well, I wasn't talking about any of those subsystems, I was talking
>> > about networking :)
>> 
>> My experience has been that networking in the strict sense of XDP no
>> longer exists on its own without cgroups, flow dissector, sockops,
>> sockmap, tracing, etc. All of these pieces are built, patched, loaded,
>> pinned and otherwise managed and manipulated as BPF objects via libbpf.
>> 
>> Because I have all this infra in place for other items its a bit odd
>> imo to drop out of BPF apis to then swap a program differently in the
>> XDP case from how I would swap a program in any other place. I'm
>> assuming ability to swap links will be enabled at some point.
>> 
>> Granted it just means I have some extra functions on the side to manage
>> the swap similar to how 'qdisc' would be handled today but still not as
>> nice an experience in my case as if it was handled natively.
>> 
>> Anyways the netlink API is going to have to call into the BPF infra
>> on the kernel side for verification, etc so its already not pure
>> networking.
>> 
>> > 
>> > In particular, networking already has a consistent and fairly
>> > well-designed configuration mechanism (i.e., netlink) that we are
>> > generally trying to move more functionality *towards* not *away from*
>> > (see, e.g., converting ethtool to use netlink).
>> 
>> True. But BPF programs are going to exist and interop with other
>> programs not exactly in the networking space. Actually library calls
>> might be used in tracing, cgroups, and XDP side. It gets a bit more
>> interesting if the "same" object file (with some patching) runs in both
>> XDP and sockops land for example.
>
> Thanks John for summarizing it very well.
> It looks to me that netlink proponents fail to realize that "bpf for
> networking" goes way beyond what netlink is doing and capable of doing in the
> future. BPF_*_INET_* progs do core networking without any smell of netlink
> anywhere. "But, but, but, netlink is the way to configure networking"... is
> simply not true.

That was not what I was saying. Obviously there are other components to
the networking stack than netlink.

What I'm saying is that netlink is the interface the kernel uses to
*configure network devices*. And that attaching an XDP program is a
network device configuration operation. I mean, it:

- Relies on the RTNL lock for synchronisation
- Fundamentally alters the flow of network packets on the device
- Potentially has side effects like link up/down, HWQ reconfig etc

I'm wondering if there's a way to reconcile these views? Maybe making
the bpf_link attachment work by passing the link fd to the netlink API?
That would keep the network interface configuration over netlink, but
would still allow a BPF application to swap out "its" programs via the
bpf_link APIs?

-Toke