Re: [PATCH bpf-next 0/9] xdp: Support multiple programs on a single interface through chain calls

[John Fastabend <john.fastabend@gmail.com>]

Edward Cree wrote:
> On 03/10/2019 15:33, Toke Høiland-Jørgensen wrote:
> > In all cases, the sysadmin can't (or doesn't want to) modify any of the
> > XDP programs. In fact, they may just be installed as pre-compiled .so
> > BPF files on his system. So he needs to be able to configure the call
> > chain of different programs without modifying the eBPF program source
> > code.
> Perhaps I'm being dumb, but can't we solve this if we make linking work?
> I.e. myIDS.so has ids_main() function, myFirewall.so has firewall()
>  function, and sysadmin writes a little XDP prog to call these:
> 
> int main(struct xdp_md *ctx)
> {
>         int rc = firewall(ctx), rc2;
> 
>         switch(rc) {
>         case XDP_DROP:
>         case XDP_ABORTED:
>         default:
>                 return rc;
>         case XDP_PASS:
>                 return ids_main(ctx);
>         case XDP_TX:
>         case XDP_REDIRECT:
>                 rc2 = ids_main(ctx);
>                 if (rc2 == XDP_PASS)
>                         return rc;
>                 return rc2;
>         }
> }
> 
> Now he compiles this and links it against those .so files, giving him
>  a new object file which he can then install.
> 
> (One problem which does spring to mind is that the .so files may very
>  inconsiderately both name their entry points main(), which makes
>  linking against both of them rather challenging.  But I think that
>  can be worked around with a sufficiently clever linker).

I agree but the same could be done today if ids_main and firewall
were inline functions. Admin can write their little program like above
and just '#include firewall', '#include ids'. Then you don't need
linking although it does make things nicer.

> 
> -Ed