Jakub Kicinski <kuba@xxxxxxxxxx> writes: > On Wed, 4 Mar 2020 17:07:08 -0800, Alexei Starovoitov wrote: >> > 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@xxxxxxx
