On Thu, Mar 26, 2020 at 10:04:53AM +0000, Lorenz Bauer wrote:

On Thu, 26 Mar 2020 at 00:16, Andrii Nakryiko [off-list ref] wrote:

quoted

[...]

quoted

Those same folks have similar concern with XDP. In the world where
container management installs "root" XDP program which other user
applications can plug into (libxdp use case, right?), it's crucial to
ensure that this root XDP program is not accidentally overwritten by
some well-meaning, but not overly cautious developer experimenting in
his own container with XDP programs. This is where bpf_link ownership
plays a huge role. Tupperware agent (FB's container management agent)
would install root XDP program and will hold onto this bpf_link
without sharing it with other applications. That will guarantee that
the system will be stable and can't be compromised.

Thanks for the extensive explanation Andrii.

This is what I imagine you're referring to: Tupperware creates a new network
namespace ns1 and a veth0<>veth1 pair, moves one of the veth devices
(let's says veth1) into ns1 and runs an application in ns1. On which veth
would the XDP program go?

As you can imagine there are many teams and use cases in the data center.
If I say that netns is not used it won't be true. Since there are folks
that use netns. Though it's strongly discouraged.
For container usage though netns is not used. IP virtualization is done
via cgroup-bpf bind/connect override.
But it's also not in 100% of containers.
There are various teams that use XDP already and some that want to start
using it. The XDP orchestration is lacking. That's all the discussions
around libxdp (and now renamed to libdispatcher, right Toke?) are about.
The design of libdispatcher will evolve over time.
No one is saying that we thought through of everything.