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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 4 Oct 2019 11:34:26 +0100
From:   Edward Cree <ecree@...arflare.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>,
        "John Fastabend" <john.fastabend@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Lorenz Bauer <lmb@...udflare.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>,
        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

On 04/10/2019 09:09, Toke Høiland-Jørgensen wrote:
> Having the mechanism be in-kernel makes solving these problems a lot
> easier, because the kernel can be responsible for state management, and
> it can enforce the chain call execution logic.
I would argue this isn't mechanism, but rather policy, because the
 mechanism we already have is sufficient to express the policy.

Enforcement is easily dealt with: you just don't give people the caps/
 perms to load XDP programs directly, so the only way they can do it is
 via your loader (which you give them a socket or dbus or something to
 talk to).  (Whereas your chain map doesn't really 'enforce' anything;
 anyone who can add themselves to the chain can also remove others.)
Then state inspection happens by querying the loader; if we assume that
 the distro provided the central loader, then they can also include the
 query in their standard system-dump tools.
Dynamic changes would just mean compiling a new dispatcher, then
 atomically replacing the old prog with the new (which we can already
 do), since the central loader daemon knows the call graph and can make
 changed versions easily.
Centralisation is something that happens normally in userspace; just
 count how many daemons your favourite init system runs to administer
 system resources and multiplex requests.  Probably we'd end up with
 one or two standard loaders and interfaces to them.
In any case, it seems like XDP users in userspace still need to
 communicate with each other in order to update the chain map (which
 seems to rely on knowing where one's own program fits into it); you
 suggest they might communicate through the chain map itself, and then
 veer off into the weeds of finding race-free ways of doing that.  This
 seems (to me) needlessly complex.

Incidentally, there's also a performance advantage to an eBPF dispatcher,
 because it means the calls to the individual programs can be JITted and
 therefore be direct, whereas an in-kernel data-driven dispatcher has to
 use indirect calls (*waves at spectre*).

> The fact that Lorenz et al are interested in this feature (even though
> they are essentially already doing what you suggested, by having a
> centralised daemon to manage all XDP programs), tells me that having
> kernel support for this is the right thing to do.
Maybe Lorenz could describe what he sees as the difficulties with the
 centralised daemon approach.  In what ways is his current "xdpd"
 solution unsatisfactory?

-Ed