Date:   Mon, 30 Mar 2020 21:01:12 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Toke Høiland-Jørgensen <toke@...hat.com>,
        John Fastabend <john.fastabend@...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

On Mon, Mar 30, 2020 at 04:41:46PM +0100, Edward Cree wrote:
> On 29/03/2020 21:23, Andrii Nakryiko wrote:
> > But you can't say the same about other XDP applications that do not
> > use libxdp. So will your library come with a huge warning
> What about a system-wide policy switch to decide whether replacing/
>  removing an XDP program without EXPECTED_FD is allowed?  That way
>  the sysadmin gets to choose whether it's the firewall or the packet
>  analyser that breaks, rather than baking a policy into the design.
> Then libxdp just needs to say in the README "you might want to turn
>  on this switch".  Or maybe it defaults to on, and the other program
>  has to talk you into turning it off if it wants to be 'ill-behaved'.

yeah. something like this can work for xdp only, but
it won't work for tc, since ownership is missing.
It looks like such policy knob will bere-inventing bpf_link for
one specific xdp case only because xdp has one program per attachment.

Imagine it was easy to come up with sensible policy and allow
multiple progs in xdp hook.
How would you implement such policy knob?
processA attaches prog XDP_A. processB attaches prog XDP-B.
Unless they start tagging their indivdual programs with BTF tags
(as Toke is planning to do) there is no way to tell them apart.
Then processA can iterate all progs in a hook, finds its prog
based on tag and tell kernel: "find and replace an xdp prog with old_fd
with new_fd on this ifindex".
Kinda works, but it doesn't stop processB to accidently detach prog XDP_A
that was installed by processA.

The kernel job is to share the system resources. Like memory, cpu time.
The hook is such resource too. The owner concept part of bpf_link
allows such sharing.

> Either way, affected users will be driven to the kernel's
>  documentation for the policy switch, where we can tell them whatever
>  we think they need to know.

In the data center there are no users. Few months back I described it
the single user system. A bunch of processes are competing for resources.
They can be all root, or all nobody, or containers with userns.
Neither user id nor caps can be such separator among processes for
the job of sharing bpf hook.
The tc/xdp/cgroup/tracing bpf attachment points need to be safely
shared among N root processes that are not cooperating with each other.
For tc, cgroup, tracing the problem is solved with bpf_link, since
they all allow multi prog.
XDP is the hardest, since it does single prog only.
That's what we're trying to solve with libdispatcher.
I think if it goes well it can become part of the kernel and kernel
will do multi prog XDP attach. And all hooks will be symmetrical.
But looking at the size of this thread and still lots of misunderstanding
about basic concept like bpf_link I'm not hopeful that libdispatcher
will ever become part of the kernel.

Powered by blists - more mailing lists