On Thu, Mar 26, 2020 at 10:47:55AM -0700, Jakub Kicinski wrote:

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

quoted

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

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?

The way I understand it, veth1 would have XDP, and the application in ns1 would
be prevented from attaching a new program? Maybe you can elaborate on this
a little.

Nope, there is no veths involved. Tupperware mediates the requests 
from containers to install programs on the physical interface for
heavy-duty network processing like DDoS protection for the entire
machine.

that's not what is happening.
Jakub, I strongly suggest to avoid talking about things you have no clue.