On Thu, Mar 26, 2020 at 10:04:53AM +0000, Lorenz Bauer wrote: > On Thu, 26 Mar 2020 at 00:16, Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > [...] > > > > 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.
