[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5d964d8ccfd90_55732aec43fe05c47b@john-XPS-13-9370.notmuch>
Date: Thu, 03 Oct 2019 12:35:40 -0700
From: John Fastabend <john.fastabend@...il.com>
To: Edward Cree <ecree@...arflare.com>,
Toke Høiland-Jørgensen <toke@...hat.com>,
Alexei Starovoitov <alexei.starovoitov@...il.com>,
Jesper Dangaard Brouer <brouer@...hat.com>
Cc: Song Liu <songliubraving@...com>,
Daniel Borkmann <daniel@...earbox.net>,
Alexei Starovoitov <ast@...nel.org>, Martin Lau <kafai@...com>,
Yonghong Song <yhs@...com>,
Marek Majkowski <marek@...udflare.com>,
Lorenz Bauer <lmb@...udflare.com>,
David Miller <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 0/9] xdp: Support multiple programs on a single
interface through chain calls
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
Powered by blists - more mailing lists