Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel abstraction

From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Toke Høiland-Jørgensen" <toke@redhat.com>,
	"Alexei Starovoitov" <ast@fb.com>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii.nakryiko@gmail.com>,
	"Andrii Nakryiko" <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	"Kernel Team" <kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 0/3] Introduce pinnable bpf_link kernel abstraction
Date: Wed, 4 Mar 2020 12:45:07 -0800	[thread overview]
Message-ID: <20200304204506.wli3enu5w25b35h7@ast-mbp> (raw)
In-Reply-To: <20200304114000.56888dac@kicinski-fedora-PC1C0HJN>

On Wed, Mar 04, 2020 at 11:41:58AM -0800, Jakub Kicinski wrote:
> On Tue, 3 Mar 2020 20:36:45 -0800 Alexei Starovoitov wrote:
> > > > libxdp can choose to pin it in some libxdp specific location, so other
> > > > libxdp-enabled applications can find it in the same location, detach,
> > > > replace, modify, but random app that wants to hack an xdp prog won't
> > > > be able to mess with it.  
> > > 
> > > What if that "random app" comes first, and keeps holding on to the link
> > > fd? Then the admin essentially has to start killing processes until they
> > > find the one that has the device locked, no?  
> > 
> > Of course not. We have to provide an api to make it easy to discover
> > what process holds that link and where it's pinned.
> 
> That API to discover ownership would be useful but it's on the BPF side.

it's on bpf side because it's bpf specific.

> We have netlink notifications in networking world. The application
> which doesn't want its program replaced should simply listen to the
> netlink notifications and act if something goes wrong.

instead of locking the bike let's setup a camera and monitor the bike
when somebody steals it.
and then what? chase the thief and bring the bike back?

> > But if we go with notifier approach none of it is an issue.
> 
> Sorry, what's the notifier approach? You mean netdev notifier chain 
> or something new?

that's tbd.

> > Whether target obj is held or notifier is used everything I said before still
> > stands. "random app" that uses netlink after libdispatcher got its link FD will
> > not be able to mess with carefully orchestrated setup done by libdispatcher.
> > 
> > Also either approach will guarantee that infamous message:
> > "unregister_netdevice: waiting for %s to become free. Usage count"
> > users will never see.
> >
> > > And what about the case where the link fd is pinned on a bpffs that is
> > > no longer available? I.e., if a netdevice with an XDP program moves
> > > namespaces and no longer has access to the original bpffs, that XDP
> > > program would essentially become immutable?  
> > 
> > 'immutable' will not be possible.
> > I'm not clear to me how bpffs is going to disappear. What do you mean
> > exactly?
> > 
> > > > We didn't come up with these design choices overnight. It came from
> > > > hard lessons learned while deploying xdp, tc and cgroup in production.
> > > > Legacy apis will not be deprecated, of course.  
> 
> This sounds like a version of devm_* helpers for configuration.
> Why are current user space APIs insufficient? 

current xdp, tc, cgroup apis don't have the concept of the link
and owner of that link.

> Surely all of this can 
> be done from user space.

with a camera for theft monitoring. that will work well.

> And we will need a centralized daemon for XDP
> dispatch, so why is it not a part of a daemon?

current design of libdispatcher doesn't need the deamon.