On Tue, Jul 4, 2023 at 6:01 PM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > On 7/4/23 11:36 PM, Jamal Hadi Salim wrote: > > On Thu, Jun 8, 2023 at 5:25 PM Andrii Nakryiko > > <andrii.nakryiko@xxxxxxxxx> wrote: > >> On Thu, Jun 8, 2023 at 12:46 PM Jamal Hadi Salim <jhs@xxxxxxxxxxxx> wrote: > >>> On Thu, Jun 8, 2023 at 6:12 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > >>>> On 6/8/23 3:25 AM, Jamal Hadi Salim wrote: > [...] > >>>> BPF links are supported for XDP today, just tc BPF is one of the few > >>>> remainders where it is not the case, hence the work of this series. What > >>>> XDP lacks today however is multi-prog support. With the bpf_mprog concept > >>>> that could be addressed with that common/uniform api (and Andrii expressed > >>>> interest in integrating this also for cgroup progs), so yes, various hook > >>>> points/program types could benefit from it. > >>> > >>> Is there some sample XDP related i could look at? Let me describe our > >>> use case: lets say we load an ebpf program foo attached to XDP of a > >>> netdev and then something further upstream in the stack is consuming > >>> the results of that ebpf XDP program. For some reason someone, at some > >>> point, decides to replace the XDP prog with a different one - and the > >>> new prog does a very different thing. Could we stop the replacement > >>> with the link mechanism you describe? i.e the program is still loaded > >>> but is no longer attached to the netdev. > >> > >> If you initially attached an XDP program using BPF link api > >> (LINK_CREATE command in bpf() syscall), then subsequent attachment to > >> the same interface (of a new link or program with BPF_PROG_ATTACH) > >> will fail until the current BPF link is detached through closing its > >> last fd. > > > > So this works as advertised. The problem is however not totally solved > > because it seems we need a process that's alive to hold the ownership. > > If we had a daemon then that would solve it i think (we dont). > > Alternatively, you pin the link. The pinning part can be > > circumvented, unless i misunderstood i,e anybody with the right > > permissions can remove it. > > > > Am I missing something? > > It would be either of those depending on the use case, and for pinning > removal, it would require right permissions/acls. Keep in mind that for > your application you can also use your own bpffs mount, so you don't > need to use the default /sys/fs/bpf one in hostns. This helps for sure - doesnt 100% solve it. It would really be nice if we could tie in a kerberos-like ticketing system for ownership of the mount or something even more fine grained like a link. Doesnt have to be kerberos but anything that would allow a digest of some verifiable credentials/token to be handed to the kernel for authorization... cheers, jamal > Thanks, > Daniel
