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

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 4 Mar 2020 12:45:07 -0800 Alexei Starovoitov wrote:
> 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?

:) Is the bike the BPF program? It's more like thief is stealing our
parking spot, we still have the program :)

Maybe also the thief should not have CAP_ADMIN in the first place?
And ask a daemon to perform its actions..

> > > 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.

Why do the attachment points have to have a concept of an owner and 
not the program itself?

Link is a very overloaded term, I may not comprehend very well that 
it models because of that.

> > 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.

Which is flawed. Why do we want to solve a distributed problem 
of multiple applications with potentially a different version 
of a library cooperating. When we can make it a daemon.