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
