Jakub Kicinski [off-list ref] writes:

On Wed, 4 Mar 2020 17:07:08 -0800, Alexei Starovoitov wrote:

quoted

quoted

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

a daemon idea keeps coming back in circles.
With FD-based kprobe/uprobe/tracepoint/fexit/fentry that problem is gone,
but xdp, tc, cgroup still don't have the owner concept.
Some people argued that these three need three separate daemons.
Especially since cgroups are mainly managed by systemd plus container
manager it's quite different from networking (xdp, tc) where something
like 'networkd' might makes sense.
But if you take this line of thought all the ways systemd should be that
single daemon to coordinate attaching to xdp, tc, cgroup because
in many cases cgroup and tc progs have to coordinate the work.

The feature creep could happen, but Toke's proposal has a fairly simple
feature set, which should be easy to cover by a stand alone daemon.

Toke, I saw that in the library discussion there was no mention of 
a daemon, what makes a daemon solution unsuitable?

Quoting from the last discussion[0]:

- Introducing a new, separate code base that we'll have to write, support
  and manage updates to.

- Add a new dependency to using XDP (now you not only need the kernel
  and libraries, you'll also need the daemon).

- Have to duplicate or wrap functionality currently found in the kernel;
  at least:
  
    - Keeping track of which XDP programs are loaded and attached to
      each interface (as well as the "new state" of their attachment
      order).

    - Some kind of interface with the verifier; if an app does
      xdpd_rpc_load(prog), how is the verifier result going to get back
      to the caller?

- Have to deal with state synchronisation issues (how does xdpd handle
  kernel state changing from underneath it?).

While these are issues that are (probably) all solvable, I think the
cost of solving them is far higher than putting the support into the
kernel. Which is why I think kernel support is the best solution :)

The context was slightly different, since this was before we had
freplace support in the kernel. But apart from the point about the
verifier, I think the arguments still stand. In fact, now that we have
that, we don't even need userspace linking, so basically a daemon's only
task would be to arbitrate access to the XDP hook? In my book,
arbitrating access to resources is what the kernel is all about...

-Toke

[0] https://lore.kernel.org/bpf/m/874l07fu61.fsf@toke.dk (local)